Hi, maybe s/do not exit/complain/? Because it still exits if the hashes are Is it really intended that it returns 0 now? Further, should it not be an error("%s missin... instead? It is an error, isn't it? Ciao, Dscho --

Stacked GIT 0.14.3 release is available from http://www.procode.org/stgit/. StGIT is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of GIT. These operations are performed using GIT commands and the patches are stored as GIT commit objects, allowing easy merging of the StGIT patches into other repositories using standard GIT functionality. This is a maintenance release including bug-fixes for the "refresh" command, handling ...

Heh, thanks for being picky ;-) Something this small, either way is fine by me. Besides, I've applied the patch (and the other one) from Boyd already. --

Saving at the beginning to use in test_done, and optionally detecting Yup. That is what I meant by "not immediate, but something to keep in mind". --

Well, the point of the exercise is to split a *single* commit into a "base" commit (already available, possibly on another branch) and a "delta" (the amending, transformed into an independent commit whose parent is the "base"). Indeed you can do that for any commit. The script uses the "git-merge-base" to compute the "base", and takes the following commit (on the path to HEAD) as the "delta". That's what add the restriction. You can definitely make a two-argument variation that, ...

I cannot rename remote branch (possibly packed, and possibly with reflog) using "git branch" [gitweb/web@git]$ git branch -m refs/remotes/gitweb-caching/master \ refs/remotes/gitweb-kernel.org/master error: refname refs/heads/refs/remotes/gitweb-caching/master not found fatal: Branch rename failed [gitweb/web@git]$ git branch -m gitweb-caching/master \ gitweb-kernel.org/master error: refname refs/heads/gitweb-caching/master not ...

[Empty message]

By the way, if you want to send large series of patches, and you have your git repository published somewhere (repo.or.cz, gitorious, github, freedektop, kernel.org), sometimes pull request is used. As you usually use git-format-patch (perhaps together with git-send-email) when sending patches, you can use output of git-request-pull there. Strange. While in git-diff family of commands '-p' means generate diff in patchset format: -p Generate patch (see section on generating ...

I moved the message from above my commiter message because I was told to add comments after the --- with the file being modified. The reasons for the modifications. I used git format-patch -p -M -B origin to generate this email. All I did was read the contents into the email I create for posting. This was the advice I was given on IRC as the best method to create/send the patch. When on IRC I was omitting the -p and was not getting the .patch file. After reading the docs over and ...

Above info is neither in commit message, not in comment in some file. It would be nice to have it in somewhere, and not only in mailing list archives. -- Jakub Narebski Poland ShadeHawk on #git --

This was from my own copy of the master archive. It is my proposal. I thought you had to get an OK from this list before you do a push to the main archive. Am I missing something? I am new to this list and the proper methods for submitting patches. I thought I was following the guidelines from http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD What am I missing? -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah ...

So the patch should be From: Boyd Lynn Gerber <gerberb@zenez.com> Date: Sun, 8 Jun 2008 11:41:46 -0600 [PATCH] Port to 12 other Platforms. This patch adds support to compile and run git on 12 additional platforms. The platforms are based on UNIX Systems Labs (USL)/Novell/SYS V code base. The most common are Novell UnixWare 2.X.X, SCO UnixWare 7.X.X, OpenServer 5.0.X, OpenServer 6.0.X, and SCO pre OSR 5 platforms. This is from # 1 "/usr/include/netinet/tcp_f.h" The problem is that ...

This patch adds support to compile and run git on 12 additional platforms. The platforms are based on UNIX Systems Labs (USL)/Novell/SYS V code base. The most common are Novell UnixWare 2.X.X, SCO UnixWare 7.X.X, OpenServer 5.0.X, OpenServer 6.0.X, and SCO pre OSR 5 platforms. This is from The problem is that git source has blocked some typedefs by excluding certain <sys/types.h> content. Looking at the the various platform header, I see around line 450 && ...

Sorry type-o should have been git clone git://www.zenez.com/git git -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --

It is just a temporary buffer, there is no urgent need to micro-optimize the allocation like that. Maybe just leave one of the buffers, the one on stack? It is just a progress message, snprintf will cut it, yes, but it is unlikely to cause any harm (unless you forget to \n-terminate it). --

Dynamically sized arrays are gcc and C99 construct. Using them hurts portability to older compilers, although using them is nice in this case it is not desirable. This patch removes the only use of the construct in stop_progress_msg(); the function is about writing out a single line of a message, and the existing callers of this function feed messages of only bounded size anyway, so use of dynamic array is simply overkill. Signed-off-by: Boyd Lynn Gerber <gerberb@zenez.com> -- Boyd ...

I may be mistaken but isn't this Junio's patch? If so (quoting from SubmittingPatches document): If you are forwarding a patch from somebody else, optionally, at the beginning of the e-mail message just before the commit message starts, you can put a "From: " line to name that person. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ---------------------------------------------------------------------- Find out how you can get spam free ...

This helps porting to Windows. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- path.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/path.c b/path.c index 7c3b89a..5da41c7 100644 --- a/path.c +++ b/path.c @@ -321,7 +321,7 @@ const char *make_nonrelative_path(const char *path) { static char buf[PATH_MAX + 1]; - if (path[0] == '/') { + if (is_absolute_path(path)) { if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) die ("Too long path: ...

Errr... it looks like you forgot to update commit message. But that aside, I quite like this series. -- Jakub Narebski Poland ShadeHawk on #git --

From: Miklos Vajna <vmiklos@frugalware.org> This is a simple script that aggregates key:value pairs in a file. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- t/aggregate-results.sh | 33 +++++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100755 t/aggregate-results.sh diff --git a/t/aggregate-results.sh b/t/aggregate-results.sh new file mode 100755 index 0000000..9e4322c --- /dev/null +++ b/t/aggregate-results.sh @@ -0,0 +1,33 ...

Hi Cyrill, Imho, that's a fairly elegant way to do that. You might want to have a look at git-bundle as well. However, that's not suited for moving the whole repository, but rather to exchange patches without being able to use any network based protocols. HTH, Sebastian --=20 Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin ...

[Sebastian Harl - Sun, Jun 08, 2008 at 03:59:49PM +0200] | Hi Cyrill, | | On Sun, Jun 08, 2008 at 05:46:01PM +0400, Cyrill Gorcunov wrote: | > could someone say me if there is a way to pack git repo in a single | > file somehow? I mean - sometime I have to move _whole_ git database | > by some media without net access so I can't fetch it. Usually I just | > create tar.gz for .git directory and copy it to some media then unpack | > it in place where I need. But maybe there is some other more ...

Hi, I want to do a kind of manual rebase where I check out an older version of a branch and simply re-apply a selection of the commits following this point in history. So in this specific case, I want to check out v2.6.25 of linux-2.6.git and re-apply all the changes that were made to the file net/mac80211/rc80211_pid_algo.c between v2.6.25 and v2.6.26-rc4. In order to determine which commits I need, I used the following command: $ git log --follow v2.6.25..v2.6.26-rc4 ...

This patch adds support to compile git on 12 additional platforms. The platforms are based on UNIX Systems Labs (USL)/Novell/SYS V code base. This patch also adds support for Novell UnixWare 2.x.x, UnixWare 7.1.4 and older, OpenServer 5.0.7 and older OpenServer 6.0.X, and SCO pre OSR 5 platforms to build and run git. This is with suggestions and modifications from Daniel Barkalow <barkalow@iabervon.org> Junio C Hamano <gitster@pobox.com> Thomas Harning <harningt@gmail.com> Jeremy ...

I'll also retitle it to "gitweb setup instruction: rewrite HEAD and root as well". Please sign-off your future patches. Thanks. --

Hello, The git-remote documentation talks about a mysterious -n option for show and prune that comes from the old git-remote.perl script. This flag was used to prevent the script from calling ls-remote more than once, FWIU. Today, the builtin accept an (un)?related -n(--dry-run) flag that does nothing, actually. It seems broken. So, is it safe to drop it entirely or is it better to just remove it from the documentation for compatibility? In the second case, how long should we wait before ...

From: Olivier Marin <dkr@freesurf.fr> This option comes from the original git-remote.perl script and is not used nor needed in the current builtin. So, remove it from the documentation so that we can reuse it later for something else. Signed-off-by: Olivier Marin <dkr@freesurf.fr> --- My MUA destroyed the previous patch! Sorry. Documentation/git-remote.txt | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/Documentation/git-remote.txt ...

Hi Does git-svn support a repository layout where branches may reside under more than one root? /trunk /branches branch1 branch2 branch3 /somedir branch4 branch5 branch6 /tags ... -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen@xorcom.com +972-50-7952406 mailto:tzafrir.cohen@xorcom.com http://www.xorcom.com iax:guest@local.xorcom.com/tzafrir --

You can just add more svn-remote to a single git repo with "git svn init". So you could do: git svn clone -s svn://host/some/repo cd repo git svn init --branches somedir svn://host/some/repo/ svn2 git svn fetch svn2 To fetch all new stuff at once, you would then later use "git svn fetch --all". Björn --

Hi, I prefer a response in the existing thread, but I guess it is a matter of personal taste (of the poster). Ciao, Dscho --

Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- See commit 2cf9f445e9074df1a45f5179cef0d4bb8647dd8 Documentation/git-name-rev.txt | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt index 12784d7..ffac3f8 100644 --- a/Documentation/git-name-rev.txt +++ b/Documentation/git-name-rev.txt @@ -41,6 +41,13 @@ OPTIONS of linkgit:git-describe[1] more closely. This option cannot be combined with ...

And split the "-c or -C <commit>" item into two separate items. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Hi, so here's the first one ;-) Documentation/git-commit.txt | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 40bf63e..a94b4e3 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -57,14 +57,16 @@ OPTIONS been modified and deleted, but new ...

Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- See commit da2478dbb000436b79e813ba7f243d6042f26e66 Documentation/git-describe.txt | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 3f0b7b2..9f6f483 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -70,6 +70,9 @@ OPTIONS Only consider tags matching the given pattern (can be used to avoid leaking private ...

In your scenario, is the above "sudo -u gitadm" the exact command line The thing is, I personally hate pseudo and wish that your solution did not rely on SUDO_UID which is too specific to that hack. Sometimes people need to lie to their SCM when doing things in behalf of somebody else, and I agree we would want to give them a way to do so. And we do, just like RCS and CVS honor LOGNAME. If you have /etc/hosts under RCS control but you do not want all the log entries to say 'root', and ...

Hmm. I do not know if it breaks anything, but if you are indeed in a bare repository, the files the codepaths affected try to read would not exist anyway, so I am not sure what this would fix, other than changing the behaviour of check-attr from noticing that it was asked for nonsense and bail out to not noticing nor saying anything useful. --

The patch does two things: it fixes git-check-attr to work in a bare repository, and it makes git ignore .gitattributes files in bare repositories. True, the latter is fixable by simply not creating these files in the first place. Duy somehow ended up with them, though, and reported it as strange that they are not ignored. And I agree: if we don't have a work tree then we should not look at it. :-) René --

Hi, You still have to move the subject line where it belongs, so I think the value of --paste is limited. You do have to pay attention anyway (for example when imitating how other people do it), so I think the current state should be fine. Ciao, Dscho --

As others have pointed out, the usual way for using format-patch is to create an mbox that you then pull into your MUA (e.g., I do "git format-patch --stdout origin >mbox; mutt -f mbox"). However, sometimes it is desirable to cut and paste, either because it is inconvenient to bring the message into your MUA this way, or if you are just putting a commit into an email you have already started writing. I was going to suggest a "--paste" option for format-patch which would produce a nicer ...

$ sed -ne '/sticked/,/^$/p' Documentation/gitcli.txt * when a command line option takes an argument, use the 'sticked' form. In other words, write `"git foo -oArg"` instead of `"git foo -o Arg"` for short options, and `"git foo --long-opt=Arg"` instead of `"git foo --long-opt Arg"` for long options. An option that takes optional option-argument must be written in the 'sticked' form. 'sticked' form must be used: ---------------------------- $ git describe --abbrev HEAD # ...

Hmm, anyway you do want to test what this strategy would do --- before merging. The point of "ours"/"theirs" is AFAICS that they *cannot* produce broken trees (they can cause you to lose committed stuff if used carelessly, but the resulting tree is already in some branch and supposedly has already been tested). So breaking the symmetry would not be good probably. I guess I see the reason why "ours" is more useful than "theirs". The reason is that rebase (and "rebase -i" in ...

This patch allows some older OS's, UNIX Systems Labs (USL)/Novell and SYS V based OS's, SCO OpenServer 5.0.X, SCO UnixWare 7.1.4, OpenServer 6.0.X and SCO pre OSR 5 OS's to build and run git. Applied suggestions from list. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license ...

So I should have --- Makefile Add changes for System V, UnixWare, SCO OS's --- git-compat-util.h __USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived compiler and/or some SysV based OS's. __M_UNIX indicates XENIX/SCO UNIX/OpenServer before 5.0.7 and prior release of and SCO OS. It is used just like Apple and BSD, both of these shouldn't have _XOPEN_SOURCE defined. --- progress.c Changes for older OS's that do not support the current methods for ...

Thank you all for your fast answers! I must confess I've overseen -M, as I saw --no-renames and searched for --renames. Very nice syntax, somehow guessed that this is available, but didn't try... my fault.=20 Perhaps we should reference git-rev-list(1) from git-diff(1), too? Sincerly Nico --=20 Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C

Hi, This patch is not meant for inclusion, as indicated by the "TOY PATCH" prefix. Ciao, Dscho --

What a pity! :-( I liked it. --

Hidden plan - once the new stgit.lib.git module is complete, we can mechanism. -- Catalin --

If caching is enabled, then parent info can be retrieved from cache. If caching is disabled, or cache expired (cache miss) you would have to get whole blame output to get all revisions to get parents for. This means for a short while twice amount of memory (whole blame in git-blame, because thats how non-incremental blame works, and whole blame in gitweb, till reading last byte of blame when git-blame ends); and that is not good when memory-based cache (be it memcache, mmap, or other solution) ...

Just did some tests and noted that the shell and git does not support them. I guess I thought that they work because [:alpha:] matched "a". Hi Robin The bash shell doesn't support [:alpha:] too: $ mkdir test $ cd test $ touch a $ touch b $ touch : The fnmatch function of the python module fnmatch example: $python >>> from fnmatch import fnmatch >>> fnmatch("a","[:alpha:]") False So I see no reason for displaying a warning. Best regards, Florian --

Robin Rosenberg wrote: >> + super(String.format("No repository found for file '%s'", >> + fileWeSearchedRepositoryFor)); > > This is any odd patterrn. Usually we use + to concatenate strimgs. Hi Robin, I know two good reason why you should use formating functions over string concatenation via the plus sign: 1.) formated strings are better translatable. e.g. "The string '%s' is more then %s characters long" is easier to translate then the three strings: "The string '" "' is ...

Hi, If you really think this is a bikeshed, I better spend my time elsewhere. Hth, Dscho --

Hi, That is actually where Junio convinced me that my approach is wrong: he said that you can _only_ reliably split a hunk at common lines. The thing is: if you split _not_ at a common line, the context of the second part would _change_ depending if you want to apply the first part or not. Ciao, Dscho --

Hi, Oh, sorry, I really meant the "I do not want" literally. It is just me. That does not mean that your hunk editing from within add -i has no merit. It's just that this guy is not very interested in that feature. Ciao, Dscho --

I used the 'show original message' feature, so that I could edit it before applying. I changed the name to aggregate-results.sh as suggested and changed the path to /t/test-results. Now let's see if I can make a new patch series out of this... -- Cheers, Sverre Rabbelier --

Or: $ git pull git://repo.or.cz/git/vmiklos.git stat

Sure. I would suggest: 1) Remove that ugly /tmp/git-test-results, place it under t/. 2) Resend a series indicating this is no longer a demonstration but a real series which you want to be included. ;-) Ah and it's bikesheding, but probably key_value_parser.sh is not the best name for such a script. Maybe aggregate-results.sh or something like that.

Awesome, what do you want to do with the other patches? I mean, this patch on it's own doesn't make a lot of sense, but with [1/3] and [3/3] I think it deserves some proper reviewing by the list. -- Cheers, Sverre Rabbelier --

Hi, FWIW that's what "commit --amend" and "rebase --interactive" are for. Ciao, Dscho --

git-archive uses the routines from attr.c, and this is where the ability to read attributes from git trees should be added. It's independent from ignoring files when creating archives. Maybe it would be a good idea to add this feature; in the meantime users need to resort to adding their attributes to $GIT_DIR/info/attributes. Anyway, here's a patch to add export-ignore support to git-archive. Files and directories with this attribute are not added to archives. Signed-off-by: Rene Scharfe ...