Nothing major, but I thought I'd mention it. If I pass the -c parameter to git grep, it invariably talks about /dev/null. $ git --version git version 1.5.3.1.40.g6972 $ git grep -c has_capability lib/weblib.php /dev/null:0 lib/weblib.php:29 $ git grep -c has_capability | head /dev/null:0 README.txt:0 ... cheers, m -

I am afraid this does not work either. The /dev/null here is to avoid sending a singleton filename to the external grep when we need to split the argument list, as output from "grep foo A B" and concatenation of output from "grep foo A" and "grep foo B" are different. -

As adding /dev/null may create spurious output, and that grep applied to a singleton does not works the same way than when it's applied to more than one file, split the arguments in a way that the last batch has never a singleton. Though, when there is only one file in the repository, force adding /dev/null as we cannot do anything about it. Also, as we "spare" one argument from the batch before the last (supposedly a full batch) we must be sure this batch with one element less has at least 2 e...

oh, right, now I get it, I was confused by the comment before that code, now that you explain it it looks more obvious. So the better fix is that when we split, we should never be in the case when you have a singleton :) that should be not that hard. --=20 =C2=B7O=C2=B7 Pierre Habouzit =C2=B7=C2=B7O madcoder@debia= n.org OOO http://www.madism.org

-

Usage info is emebed in the script, but the gist of it is to run the script from a pre-commit hook to save permissions/ownership data to a file and check that file into the repository. Then, a post_merge hook reads the file and updates working tree permissions/ownership. All updates are transparent to the user (although there is a --verbose option). Merge conflicts are handled in the "read" phase (in pre-commit), and the script aborts the commit and tells you how to fix things in the case of a merg...

Instead, always behave as if the force flag was given; that is, don't check if rebasing would leave a dangling commit behind. Reasons: * The check for this was very strict and caused a lot of false positives. * Everything is recorded in the reflog, so we can't actually lose commits. This fixes bug 9181. Signed-off-by: Karl Hasselström <kha@treskal.com> --- This is not in my safe branch, on purpose; I want to hear any protests and test it a bit more first. It is howev...

Unlike the cover mail diffstat, this covers exactly the selected patches and nothing else. Signed-off-by: Karl Hasselström <kha@treskal.com> --- stgit/commands/mail.py | 41 +++++++++++++++++++++++++---------------- stgit/stack.py | 7 +++++++ templates/covermail.tmpl | 3 +++ 3 files changed, 35 insertions(+), 16 deletions(-) diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py index c223665..c32894e 100644 --- a/stgit/commands/mail.py +++ b/stgit/co...

Note: The diffstat is computed from the bottom of the first patch to the top of the last, which gives a correct result if and only if the series is contiguous. This is often the case, and handling anything but this case is nontrivial, as it would involve creating a temporary series of commits that are contiguous, with all the performance and merge problems that would entail. Signed-off-by: Karl Hasselström <kha@treskal.com> --- stgit/commands/mail.py | 17 ++++++++++------- templa...

Signed-off-by: Karl Hasselström <kha@treskal.com> --- stgit/utils.py | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/stgit/utils.py b/stgit/utils.py index 02e98e9..34c0f96 100644 --- a/stgit/utils.py +++ b/stgit/utils.py @@ -214,3 +214,18 @@ def make_patch_name(msg, unacceptable, default_name = 'patch'): suffix += 1 patchname = '%s-%d' % (patchname, suffix) return patchname + +# any and all functions are builtin i...

An error from git-apply just means that the patch isn't applied. Signed-off-by: Karl Hasselström <kha@treskal.com> --- stgit/git.py | 3 ++- stgit/run.py | 9 ++++++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/stgit/git.py b/stgit/git.py index f847cce..181e10d 100644 --- a/stgit/git.py +++ b/stgit/git.py @@ -628,7 +628,8 @@ def apply_diff(rev1, rev2, check_index = True, files = None): diff_str = diff(files, rev1, rev2) if diff_str: ...

Not that I care that much, and I don't know what is done in git usually. But aren't C99 initializer safer ? (wrt struct transport_ops API possible changes in the future). --=20 =C2=B7O=C2=B7 Pierre Habouzit =C2=B7=C2=B7O madcoder@debia= n.org OOO http://www.madism.org

It has nothing to do with latest. I feel that if for some reason transport_ops need a new function, it will break silentely, whereas if you use: static const struct transport_ops bundle_transport =3D { + .set_option =3D NULL, + .get_refs_list =3D &get_refs_from_bundle, + .fetch_refs =3D &fetch_refs_from_bundle, + .fetch_objs =3D NULL, + .push =3D NULL, + .disconnect =3D &close_bundle Or even: static const struct transport_ops bundle_transport =3D { ...

Hi, As far as I am concerned, this kind of depending on newer features (this _is_ C99, right?) will not happen. So the discussion is moot. Ciao, Dscho -

Very impressed by the entire series and mildly amused. Thanks. A few C++ style comments sprinkled here and there were eyesore, but I'll hopefully survive. You seem to have a stray printf("connect to ...\n"); as the command is expected to show the list of refs it fetched from the other side, this may interfere with what the caller wants to do. The changes to t5515 test vectors worry me quite a lot, as the distinction between not-for-merge and others is what decides the outcome of a pull, but I...

I think what the tests try to catch are sensible, but I wonder if this cannot be done without hardcoding too many object this can be done without hardcoding the exact commit object name if you tag the commits while you build the test repository and give tag relative name in "$1" (you have to do "git rev-parse" ... 3ec3965 here. I'd like to keep the very low level details of how exactly object names are computed isolated to t0000 as much as possible. I also suspect this would not pass on C...

git has no notion of "given branch", does it? It can map any branch head to a particular commit at any given point of time, and any commit to one or more parents. But there is no dependable connection of some commit to a particular branch head as far as I can see. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

Then perhaps the right solution is to move it to a "DONE" pile (rather than leaving it on "IN" or deleting it entirely). It _should_ be a simple matter of just removing the N'th line of the reflog and appending it to an 'applied-stash' reflog. However, there are a few problems: - Finding the line number is non-trivial. git-stash never actually parses stash@{1}, but hands it off to rev-parse. So it is legal to say stash@{10.minutes.ago}. - When you apply a stash, there might be conf...

Originally I was trying to find the lost tip, which was made impossible due to Yes, but since reflogs *are* taken into account when pruning lost tips, So how does one unpack a packfile to extract the loose objects? mv .git/objects/pack/*.pack /tmp/git-packs for p in /tmp/git-packs/*.pack; do git unpack-objects < $p; done ? Seems like an awful lot of trouble. I'll look into patching builtin-pack-objects.c instead to accept an "--ignore-reflog" flag and prune reflog-accessible objects...

I would obviously not use the flag when I'm looking for things, but when I'm cleaning up after a workday when I *know* that everything is where it's supposed to be, as it will then let me use git-lost-found to find the single loose tip I'm interested in rather than having to wade through the 500+ lines of cruft in the reflog. No offence to the reflog inventors. It's a great thing to have to prevent users from screwing up their repos, but it sucks that you can't disable its use without either dele...

Well, I fall into a fairly uncommon category of users. Earlier I followed git development with great interest, and then other things came up that forced me to loose sight of the git list for quite some time. Now I've got time to read it again, so I *think* I know how git works, but forget that I *did* rather than *do*. Ah well. One lives and one learns. Sometimes even at the same time :-) -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB [ message continues ]

So maybe we should deprecate git-lost-found? Since that was *also* designed for the scenario where one has lost a branch tip. Anyways, in this case the lost tip was the result of a git rebase, of which there are usually 20 or so every day in my reflog. I knew what the commit- subject was (roughly), but had no idea which of the 8 straight rebases that Why? I'd have no idea where I'd end up. I can't remember exactly what I did to my branch head more than 5 revs (or 15 minutes) ago, and since th...

Ah, now this is more like it. I should have known someone would have *giggles* It works nicely with git-shortlog too. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

Note that if you truly want to get rid of unreferenced objects, you simply have to run 'git gc' or 'git repack -a -d'. The unreferenced objects will vanish, even if they were already packed previously. The new pack will simply not contain them anymore. Nicolas -

Raw timestamps would be easiest. But this is for-each-ref, not git-log. Its %(authortime) macro in the --format string does not support any sort of date formatting options. So uh, no, --pretty=format won't help me here. I'd have to make code changes to for-each-ref to allow control of how timestamps are output. Then I'd have to put magic flags into git-gui to see what version of git I'm using and assume if the flag will work or not. And if it won't then I still have to fall back into the c...