* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-01 15:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Karl Hasselström, git
In-Reply-To: <20060301145105.GB3313@spearce.org>
On 01/03/06, Shawn Pearce <spearce@spearce.org> wrote:
> [Side Note: I've suddenly stopped receiving mail from vger.
> Even majordomo isn't replying to my pleas for help. Arggh!
> Yet all other incoming email seems to be fine.]
news.gmane.org
> True. The constant reapplication does really slow it down. So does
> grabbing the reverse patch and seeing if it applies backwards
> cleanly. Neither operation is fast, and neither is really going
> to be fast.
I realised that, depending on the number of patches merged upstream,
using this option can make StGIT faster. That's because when pushing a
patch (without the --merged option), StGIT first tries a diff | apply
followed by a three-way merge (even slower) if the former method
fails. This means that for all the patches merged upstream, StGIT
tries both methods since diff | apply fails anyway. With the --merged
option, StGIT would only try the reverse-diff | apply and, if this
succeeds, it will skip the normal push methods.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to use file suffixes.
From: Shawn Pearce @ 2006-03-01 15:06 UTC (permalink / raw)
To: git
In-Reply-To: <20060301044132.GF22894@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Sometimes it is useful to unpack the unmerged stage entries
> to the same directory as the tracked file itself, but with
> a suffix indicating which stage that version came from.
> In many user interface level scripts this is being done
> by git-unpack-file followed by creating the necessary
> directory structure and then moving the file into the
> directory with the requested name. It is now possible to
> perform the same action for a larger set of files directly
> through git-checkout-index.
Junio mentioned in his ``What's in git.git'' email that he's not
sure of this command line interface:
Junio C Hamano <junkio@cox.net> wrote:
> I am not sure about the command line interface of this. Would
> it make more sense to checkout three stages in one pass?
>
> - checkout-index --suffix (Shawn Pearce)
I thought about the same thing myself when I submitted the patch
to the list. I probably should have talked a little bit about that
in the email. :-)
I thought about using instead:
--stage=all --suffix1=\#1 --suffix2\=#2 --suffix3=\#3
but then thought that the performance gains achieved by only forking
git-checkout-index once, scanning the index once, etc. were not
that big of a difference compared to the rather horrible looking
command line syntax that produced and required one to use.
If anyone has any suggestions for these options, please pass them
along. I'll rebuild the patch to pull all available stages if we
can come up with a suitable way of describing such.
--
Shawn.
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Shawn Pearce @ 2006-03-01 14:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <tnx1wxmig75.fsf@arm.com>
[Side Note: I've suddenly stopped receiving mail from vger.
Even majordomo isn't replying to my pleas for help. Arggh!
Yet all other incoming email seems to be fine.]
Catalin Marinas <catalin.marinas@arm.com> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
> > Karl Hasselstr?m <kha@treskal.com> wrote:
> >> If I make a patch series where more than one patch touches the same
> >> line, I get a lot of merge errors when upstream has accepted them and
> >> I try to merge them back.
> >
> > When pg grabs its (possibly remote) parent ("stg pull" aka pg-rebase)
> > we try to push down PatchA. If PatchA fails to push cleanly we'll
> > pop it off and try to push PatchA + PatchB. If that pushes cleanly
> > then we fold the content of PatchA into PatchB, effectively making
> > PatchA part of PatchB. If PatchA + PatchB failed to push down
> > cleanly then we pop both and retry pushing PatchA + PatchB + PatchC.
>
> How do you solve the situation where only PatchA, PatchC and PatchE
> were merged, B and D still pending? Trying combinations of patches is
> not a good idea.
Yea, ouch. pg would fold everything into E, destroying the B
and D boundary. A (not so good) workaround right now would be to
undo the rebase, pop all patches, rebase, then push one by one.
I didn't even consider this case as its not my workflow style:
at least not right now.
> As I said, if you have a big number of patches this might be pretty
> slow. Have a look at my patch for trying the reversed patches in
> reverse order. It seems to solve this problem for most of the
> cases. There are cases when this method would fail like adjacent
> changes made by third-party patches that break the context of the git
> patches and git-apply would fail. An addition to this would be to try
> a diff3 merge with the reversed patch but I don't think it's worth
> since it would become much slower.
True. The constant reapplication does really slow it down. So does
grabbing the reverse patch and seeing if it applies backwards
cleanly. Neither operation is fast, and neither is really going
to be fast.
BTW - I did read through your patch when it was posted: the reverse
apply idea is pretty slick and should work a large part of the time,
as you said. Nice addition to StGIT.
> > If that pushes down cleanly then we make PatchA and PatchB officially
> > part of PatchC.
>
> I don't agree with this. For example, patches A, B and C change the
> same line in file1 but patch A also changes file2 and patch B changed
> file3. With your approach, merging A+B+C succeeds and you make A and B
> part of C and hence move the changed to file2 and file3 in patch C.
>
> The above can happen when the maintainer only merges part of the patch
> or simply decides to merge patch C only and manually solve the
> conflict in file1 (since patch C is based on the context from patches
> A+B).
Ah, yes. The upstream maintainer who doesn't take everything.
Shame on them. :-) Shame on me for also not dealing with this
case in pg, you are completely correct that folding these patches
together in this scenario is a really bad idea.
In the one environment where I really use pg the upstream is forced
to take the entire patch: I have my own foreign SCM interface to PVCS
VM (its heavily customized crap, so I'm not going to contribute it)
and in this interface the upstream is forced to take the entire patch
every time. So right now its not a huge concern to me personally,
but if anyone else is trying to use pg it might be.
--
Shawn.
^ permalink raw reply
* impure renames / history tracking
From: Paul Jakma @ 2006-03-01 14:01 UTC (permalink / raw)
To: git list
Hi,
I'm trying to understand git better (so I can explain it better to
others, with an eye to them considering switching to git), one
question I have is about renames.
- git obviously detects pure renames perfectly well
- git doesn't however record renames, so 'impure' renames may not be
detected
My question is:
- why not record rename information explicitely in the commit object?
I.e. so as to be able to follow history information through 'impure'
renames without having to resort to heuristics.
E.g. imagine a project where development typically occurs through:
o: commit
m: merge
o---o-m--o-o-o--o----m <- project
/ / /
o-o-o-o-o--o-o-o--o-o-o <- main branch
The project merge back to main in one 'big' combined merge
(collapsing all of the commits on 'project' into one commit). This
leads to 'impure renames' being not uncommon. The desired end-result
of merging back to 'main' being to rebase 'project' as one commit
against 'main', and merge that single commit back, a la:
o---o-m--o-o-o--o----m <- project
/ / /
o-o-o-o-o--o-o-o--o-o-o---m <- main branch
\ /
o <- project_collapsed
So that 'm' on 'main' is that one commit[1].
The merits or demerits of such merging practice aside, what reason
would there be /against/ recording explicit rename information in the
commit object, so as to help browsers follow history (particularly
impure renames) better in a commit?
I.e. would there be resistance to adding meta-info rename headers
commit objects, and having diffcore and other tools to use those
headers to /augment/ their existing heuristics in detecting renames?
Thanks!
1. Git currently doesn't have 'porcelain' to do this, presumably
there'd be no objection to one?
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
It is the quality rather than the quantity that matters.
- Lucius Annaeus Seneca (4 B.C. - A.D. 65)
^ permalink raw reply
* [PATCH 2/2] git-log (internal): more options.
From: Junio C Hamano @ 2006-03-01 12:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602281504280.22647@g5.osdl.org>
This ports the following options from rev-list based git-log
implementation:
* -<n>, -n<n>, and -n <n>. I am still wondering if we want
this natively supported by setup_revisions(), which already
takes --max-count. We may want to move them in the next
round. Also I am not sure if we can get away with not
setting revs->limited when we set max-count. The latest
rev-list.c and revision.c in this series do not, so I left
them as they are.
* --pretty and --pretty=<fmt>.
* --abbrev=<n> and --no-abbrev.
The previous commit already handles time-based limiters
(--since, --until and friends). The remaining things that
rev-list based git-log happens to do are not useful in a pure
log-viewing purposes, and not ported:
* --bisect (obviously).
* --header. I am actually in favor of doing the NUL
terminated record format, but rev-list based one always
passed --pretty, which defeated this option. Maybe next
round.
* --parents. I do not think of a reason a log viewer wants
this. The flag is primarily for feeding squashed history
via pipe to downstream tools.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* comes on top of --since/--until patch which in turn comes on
top of janitorial "remove merge-order" change.
git.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
rev-list.c | 5 ++--
revision.h | 1 +
3 files changed, 72 insertions(+), 4 deletions(-)
4e365d2558356cd091ebf57f689c477a86822d53
diff --git a/git.c b/git.c
index b0da6b1..bf68dac 100644
--- a/git.c
+++ b/git.c
@@ -256,12 +256,80 @@ static int cmd_log(int argc, char **argv
struct rev_info rev;
struct commit *commit;
char *buf = xmalloc(LOGSIZE);
+ static enum cmit_fmt commit_format = CMIT_FMT_DEFAULT;
+ int abbrev = DEFAULT_ABBREV;
+ int show_parents = 0;
+ const char *commit_prefix = "commit ";
argc = setup_revisions(argc, argv, &rev, "HEAD");
+ while (1 < argc) {
+ char *arg = argv[1];
+ /* accept -<digit>, like traditilnal "head" */
+ if ((*arg == '-') && isdigit(arg[1])) {
+ rev.max_count = atoi(arg + 1);
+ }
+ else if (!strcmp(arg, "-n")) {
+ if (argc < 2)
+ die("-n requires an argument");
+ rev.max_count = atoi(argv[2]);
+ argc--; argv++;
+ }
+ else if (!strncmp(arg,"-n",2)) {
+ rev.max_count = atoi(arg + 2);
+ }
+ else if (!strncmp(arg, "--pretty", 8)) {
+ commit_format = get_commit_format(arg + 8);
+ if (commit_format == CMIT_FMT_ONELINE)
+ commit_prefix = "";
+ }
+ else if (!strcmp(arg, "--parents")) {
+ show_parents = 1;
+ }
+ else if (!strcmp(arg, "--no-abbrev")) {
+ abbrev = 0;
+ }
+ else if (!strncmp(arg, "--abbrev=", 9)) {
+ abbrev = strtoul(arg + 9, NULL, 10);
+ if (abbrev && abbrev < MINIMUM_ABBREV)
+ abbrev = MINIMUM_ABBREV;
+ else if (40 < abbrev)
+ abbrev = 40;
+ }
+ else
+ die("unrecognized argument: %s", arg);
+ argc--; argv++;
+ }
+
prepare_revision_walk(&rev);
setup_pager();
while ((commit = get_revision(&rev)) != NULL) {
- pretty_print_commit(CMIT_FMT_DEFAULT, commit, ~0, buf, LOGSIZE, 18);
+ printf("%s%s", commit_prefix,
+ sha1_to_hex(commit->object.sha1));
+ if (show_parents) {
+ struct commit_list *parents = commit->parents;
+ while (parents) {
+ struct object *o = &(parents->item->object);
+ parents = parents->next;
+ if (o->flags & TMP_MARK)
+ continue;
+ printf(" %s", sha1_to_hex(o->sha1));
+ o->flags |= TMP_MARK;
+ }
+ /* TMP_MARK is a general purpose flag that can
+ * be used locally, but the user should clean
+ * things up after it is done with them.
+ */
+ for (parents = commit->parents;
+ parents;
+ parents = parents->next)
+ parents->item->object.flags &= ~TMP_MARK;
+ }
+ if (commit_format == CMIT_FMT_ONELINE)
+ putchar(' ');
+ else
+ putchar('\n');
+ pretty_print_commit(commit_format, commit, ~0, buf,
+ LOGSIZE, abbrev);
printf("%s\n", buf);
}
free(buf);
diff --git a/rev-list.c b/rev-list.c
index 6af8d86..8e4d83e 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,10 +7,9 @@
#include "diff.h"
#include "revision.h"
-/* bits #0-3 in revision.h */
+/* bits #0-4 in revision.h */
-#define COUNTED (1u << 4)
-#define TMP_MARK (1u << 5) /* for isolated cases; clean after use */
+#define COUNTED (1u<<5)
static const char rev_list_usage[] =
"git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
diff --git a/revision.h b/revision.h
index 0043c16..31e8f61 100644
--- a/revision.h
+++ b/revision.h
@@ -5,6 +5,7 @@
#define UNINTERESTING (1u<<1)
#define TREECHANGE (1u<<2)
#define SHOWN (1u<<3)
+#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
struct rev_info {
/* Starting list */
--
1.2.3.g9425
^ permalink raw reply related
* [PATCH 1/2] git-log (internal): add approxidate.
From: Junio C Hamano @ 2006-03-01 12:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602281504280.22647@g5.osdl.org>
Next will be the pretty-print format.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> I didn't add the logic for --before/--after flags, but that should be
> pretty trivial, and is independent of this anyway.
>
> Perhaps more importantly, I didn't remove the tests that now start
> failing, nor did I remove the actual code to do --merge-order ;/
I've done the janitorial, and have two more on top. Here is the
first one. I'd appreciate comments on the second one.
revision.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
2eba658eaffdf4c5c9d0767b49e4c27d7281cda6
diff --git a/revision.c b/revision.c
index c84f146..4885871 100644
--- a/revision.c
+++ b/revision.c
@@ -492,6 +492,26 @@ int setup_revisions(int argc, const char
revs->limited = 1;
continue;
}
+ if (!strncmp(arg, "--since=", 8)) {
+ revs->max_age = approxidate(arg + 8);
+ revs->limited = 1;
+ continue;
+ }
+ if (!strncmp(arg, "--after=", 8)) {
+ revs->max_age = approxidate(arg + 8);
+ revs->limited = 1;
+ continue;
+ }
+ if (!strncmp(arg, "--before=", 9)) {
+ revs->min_age = approxidate(arg + 9);
+ revs->limited = 1;
+ continue;
+ }
+ if (!strncmp(arg, "--until=", 8)) {
+ revs->min_age = approxidate(arg + 8);
+ revs->limited = 1;
+ continue;
+ }
if (!strcmp(arg, "--all")) {
handle_all(revs, flags);
continue;
--
1.2.3.g9425
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-03-01 12:24 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- Cygwin related fixes (Alex Riesen) [*]
- git-rm fixes and docs (Carl Worth)
- gitview updates (Aneesh Kumar, Pavel Roskin)
- git-svn updates (Eric Wong)
- git-cvsserver (Martin Langhoff, Johannes Schindelin)
- git-annotate (Ryan Anderson)
- format-patch fix (Alexandre Julliard)
- fix send-pack to a remote with insanely large number of refs [*]
- "thin" pack git-push/git-fetch.
- eye candies to checkout [*].
- error() formatting fixes [*].
- git-am empty commit prevention [*].
- git-mailinfo now is built and installed again.
- fix two sample hooks [*].
- diffcore-rename and diffcore-break microfix [*].
- svnimport enhancements (Karl Hasselström)
- git-fetch output tweak (Lukas Sandström)
- start to do more things in git wrapper (Linus)
- combine-diff fixes (Mark Wooding) [*]
- ls-files -i -o fix (Shawn Pearce)
- Darwin related fix (Shawn Pearce)
- compilation warning fixes (Timo Hirvonen, Tony Luck, Andreas Ericsson)
The changes marked with [*] will appear in the next
maintenance release; they are either first applied to 1.2.X
maintenance branch and pulled into master, or first applied to
master and then cherry picked to 1.2.X maintenance branch.
* The 'next' branch, in addition, has these.
I wanted to have this out to "master", but ran out of time.
The same set of changes are already cherry-picked and waiting
for inclusion in the next maintenance release.
- git-apply trailing whitespace warning (Linus and me)
These are waiting for further progress by authors:
- git-blame (Fredrik Kuivinen)
- delta packer updates for tighter packs (Nicolas Pitre)
These are here only because they are new, not because I have
any qualms about them:
- for_each_ref warning (Johannes Schindelin)
- prepare to make rename/break detection independent from delta packing.
- checkout-index --stdin (Shawn Pearce)
These are here because they are rather important and I am
playing it safe.
- beginning of rev-list libification (Linus)
- git-log without shell script (Linus and me)
I am almost happy about this. Now the author mapping format
is the same between cvs/svn importers, would it make sense to
unify them so that other foreign scm interface can also follow
suit? Usually you would not have upstreams with two different
foreign scm to a single repository anyway, so this may not be an
issue, though...
- git-svnimport save author name mapping to a file (Karl Hasselström)
* The 'pu' branch, in addition, has these.
This is in preparation for Nico's delta work already in "next".
- make rename/break detection independent from delta packing.
These muddy the water for what is in "next", improving of
which is more important.
- diff-delta: cull collided hash bucket more aggressively.
- diff-delta: allow reusing of the reference buffer index (Nicolas Pitre)
I am not sure about the command line interface of this. Would
it make more sense to checkout three stages in one pass?
- checkout-index --suffix (Shawn Pearce)
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-01 10:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Karl Hasselström, git
In-Reply-To: <20060227222600.GA11797@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Karl Hasselstr?m <kha@treskal.com> wrote:
>> If I make a patch series where more than one patch touches the same
>> line, I get a lot of merge errors when upstream has accepted them and
>> I try to merge them back.
>
> When pg grabs its (possibly remote) parent ("stg pull" aka pg-rebase)
> we try to push down PatchA. If PatchA fails to push cleanly we'll
> pop it off and try to push PatchA + PatchB. If that pushes cleanly
> then we fold the content of PatchA into PatchB, effectively making
> PatchA part of PatchB. If PatchA + PatchB failed to push down
> cleanly then we pop both and retry pushing PatchA + PatchB + PatchC.
How do you solve the situation where only PatchA, PatchC and PatchE
were merged, B and D still pending? Trying combinations of patches is
not a good idea.
As I said, if you have a big number of patches this might be pretty
slow. Have a look at my patch for trying the reversed patches in
reverse order. It seems to solve this problem for most of the
cases. There are cases when this method would fail like adjacent
changes made by third-party patches that break the context of the git
patches and git-apply would fail. An addition to this would be to try
a diff3 merge with the reversed patch but I don't think it's worth
since it would become much slower.
> If that pushes down cleanly then we make PatchA and PatchB officially
> part of PatchC.
I don't agree with this. For example, patches A, B and C change the
same line in file1 but patch A also changes file2 and patch B changed
file3. With your approach, merging A+B+C succeeds and you make A and B
part of C and hence move the changed to file2 and file3 in patch C.
The above can happen when the maintainer only merges part of the patch
or simply decides to merge patch C only and manually solve the
conflict in file1 (since patch C is based on the context from patches
A+B).
--
Catalin
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Junio C Hamano @ 2006-03-01 10:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602281017241.25336@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
>> I tried an experimental patch to cull collided hash buckets
>> very aggressively. I haven't applied your last "reuse index"
>> patch, though -- I think that is orthogonal and I'd like to
>> leave that to the next round.
>
> It is indeed orthogonal and I think you could apply it to the next
> branch without the other patches (it should apply with little problems).
> This is an obvious and undisputable gain, even more if pack-objects is
> reworked to reduce memory usage by keeping only one live index for
> multiple consecutive deltaattempts.
Umm. The hash-index is rather huge, isn't it? I did not
realize it was two-pointer structure for every byte in the
source material, and we typically delta from larger to smaller,
so we will keep about 10x the unpacked source. Until we swap
the windowing around, that means about 100x the unpacked source
with the default window size.
Also, I am not sure which one is more costly: hash-index
building or use of that to search inside target. I somehow got
an impression that the former is relatively cheap, and that is
what is being cached here.
> Let's suppose the reference buffer has:
>
> ***********************************************************************/
>...
> One improvement might consist of counting the number of consecutive
> identical bytes when starting a compare, and manage to skip as many hash
> entries (minus the block size) before looping again with more entries in
> the same hash bucket.
Umm, again. Consecutive identical bytes (BTW, I think "* * *"
and "** ** **" patterns have the same collision issues without
being consecutive bytes, so such an optimization may be trickier
and cost more), when emitted as literals, would compress well,
wouldn't they? At the end of the day, I think what matters is
the size of deflated delta, since going to disk to read it out
is more expensive than deflating and applying. I think you made
a suggestion along the same line, capping the max delta used by
try_delta() more precisely by taking the deflated size into
account.
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Andreas Ericsson @ 2006-03-01 9:40 UTC (permalink / raw)
To: Eric Wong; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <20060301065138.GC21684@hand.yhbt.net>
Eric Wong wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
>
>>
>>On Tue, 28 Feb 2006, Martin Langhoff wrote:
>>
>>>git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
>>>Nothing within core git prevents it from moving, but I think that
>>>porcelains will start breaking. Tags and heads are the same thing,
>>>except that heads are expected to change (specifically, to move
>>>forward), and tags are expected to stand still.
>>
>><snipped>
>>Using a "refs/remotes" subdirectory makes tons of sense for something like
>>this. Or something even more specific, like "refs/svn-tracking/". Git
>>shouldn't care - all the tools _should_ work fine with any subdirectory
>>structure.
>
>
> Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'
> prefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get
> specified from the command-line quite often:
>
> git checkout -b mine git-svn-HEAD
> git-log git-svn-HEAD..head
> git-svn commit git-svn-HEAD..mine
> git-log mine..git-svn-HEAD
>
> Should rev-parse be taught to be less strict and look for basenames
> that can't be found in heads/ and tags/ in other directories?
>
It already does. The search order is this, for a ref named 'foo':
$GIT_DIR/foo
$GIT_DIR/refs/foo
$GIT_DIR/refs/tags/foo
$GIT_DIR/refs/heads/foo
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/3] Tie it all together: "git log"
From: Junio C Hamano @ 2006-03-01 9:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90602281538m90c4d04pbb6f277e3bec89e8@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 3/1/06, Junio C Hamano <junkio@cox.net> wrote:
>> I would say we should just rip merge-order out. Who uses it,
>> and why does it not work with topo-order, again?
>
> IIRC archimport uses it, but there's no reason why topo-order wouldn't work.
Thanks. I'll push out a few patches on top of Linus' series,
with s/merge-order/topo-order/ on archimport.
^ permalink raw reply
* Re: Quick question: end of lines
From: Junio C Hamano @ 2006-03-01 9:01 UTC (permalink / raw)
To: Emmanuel Guerin; +Cc: git, Martin Langhoff
In-Reply-To: <46a038f90603010031g31f8bc33xd3f45f2e19950c78@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 3/1/06, Emmanuel Guerin <emmanuel@guerin.fr.eu.org> wrote:
>> What I begin to realize is that the only possibility probably lies in
>> using a tool that converts the modified files "on the fly" before
>> commits. I just want to make sure that no other solution was found by
>> others facing a similar problem.
>
> Perhaps a pre-commit hook? Read the documentation (and search the list
> archives). I'm pretty sure you can do newline cleanup before commit or
> at least newline checks before commits.
>
> There's always the option of filing a bug in MS's bugzilla ;-)
You can use .git/hooks/pre-commit hook in the repository the
editor that munges line-termination, to fix things up.
The hook is called with GIT_INDEX_FILE set to the appropriate
index file, so you could "git-diff-index --cached --name-only
HEAD" to obtain the list of files being committed, sanitize the
working tree files and update-index them again before returning
true from the hook.
This is a silly example to standardize on uppercase.
git-diff-index --cached --name-only HEAD |
xargs sh -c '
while case "$#" in 0) break ;; esac
do
perl -p -i -e "\$_ = uc(\$_)" "$1"
git-update-index "$1"
shift
done
' dummy
exit 0
^ permalink raw reply
* Re: Quick question: end of lines
From: Martin Langhoff @ 2006-03-01 8:31 UTC (permalink / raw)
To: Emmanuel Guerin; +Cc: git
In-Reply-To: <f898cca90602281612n777a4f17m@mail.gmail.com>
On 3/1/06, Emmanuel Guerin <emmanuel@guerin.fr.eu.org> wrote:
> What I begin to realize is that the only possibility probably lies in
> using a tool that converts the modified files "on the fly" before
> commits. I just want to make sure that no other solution was found by
> others facing a similar problem.
Perhaps a pre-commit hook? Read the documentation (and search the list
archives). I'm pretty sure you can do newline cleanup before commit or
at least newline checks before commits.
There's always the option of filing a bug in MS's bugzilla ;-)
cheers,
martin
^ permalink raw reply
* Re: gitview: Set the default width of graph cell
From: Aneesh Kumar @ 2006-03-01 7:15 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <440460DC.7080307@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On 2/28/06, Aneesh Kumar K.V <aneesh.kumar@gmail.com> wrote:
>
>
> Subject: gitview: Set the default width of graph cell
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
>
> ---
>
I guess this one is better. Please apply this one . This is on top of
the previous one.
-aneesh
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git.diff --]
[-- Type: text/x-patch; name="git.diff", Size: 810 bytes --]
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index ea05cd4..de9f3f3 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -513,7 +513,7 @@ class GitView:
scrollwin = gtk.ScrolledWindow()
- scrollwin.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
+ scrollwin.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
scrollwin.set_shadow_type(gtk.SHADOW_IN)
vbox.pack_start(scrollwin, expand=True, fill=True)
scrollwin.show()
@@ -526,9 +526,6 @@ class GitView:
self.treeview.show()
cell = CellRendererGraph()
- # Set the default width to 265
- # This make sure that we have nice display with large tag names
- cell.set_property("width", 265)
column = gtk.TreeViewColumn()
column.set_resizable(True)
column.pack_start(cell, expand=True)
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-03-01 6:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0602271634410.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 28 Feb 2006, Martin Langhoff wrote:
> >
> > git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
> > Nothing within core git prevents it from moving, but I think that
> > porcelains will start breaking. Tags and heads are the same thing,
> > except that heads are expected to change (specifically, to move
> > forward), and tags are expected to stand still.
> <snipped>
> Using a "refs/remotes" subdirectory makes tons of sense for something like
> this. Or something even more specific, like "refs/svn-tracking/". Git
> shouldn't care - all the tools _should_ work fine with any subdirectory
> structure.
Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'
prefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get
specified from the command-line quite often:
git checkout -b mine git-svn-HEAD
git-log git-svn-HEAD..head
git-svn commit git-svn-HEAD..mine
git-log mine..git-svn-HEAD
Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?
--
Eric Wong
^ permalink raw reply
* [PATCH] Teach git-checkout-index to use file suffixes.
From: Shawn Pearce @ 2006-03-01 4:41 UTC (permalink / raw)
To: git
Sometimes it is useful to unpack the unmerged stage entries
to the same directory as the tracked file itself, but with
a suffix indicating which stage that version came from.
In many user interface level scripts this is being done
by git-unpack-file followed by creating the necessary
directory structure and then moving the file into the
directory with the requested name. It is now possible to
perform the same action for a larger set of files directly
through git-checkout-index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I think this completes the two features I've found missing from
git-checkout-index: --stdin and --suffix. These two options
should make writing a working directory based merge strategy
a little easier.
FYI: I built this on top of my immediately prior patch ('Teach
git-checkout-index to read filenames from stdin.') so this one
may not apply cleanly without that patch being applied first.
Documentation/git-checkout-index.txt | 29 ++++++++++++++++++++++++++++-
apply.c | 2 ++
cache.h | 2 ++
checkout-index.c | 14 ++++++++++++--
entry.c | 10 +++++++---
read-tree.c | 1 +
6 files changed, 52 insertions(+), 6 deletions(-)
base df23c1119d0af1fbac6b8afd296113e155d9a878
last e1674dc0b01de5c34fada13f7cf5fcbb3be82d09
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index b0b6588..f0be2a0 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -9,7 +9,8 @@ git-checkout-index - Copy files from the
SYNOPSIS
--------
[verse]
-'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+'git-checkout-index' [-u] [-q] [-a] [-f] [-n]
+ [--prefix=<string>] [--suffix=<string>]
[--stage=<number>]
[-z] [--stdin]
[--] [<file>]\*
@@ -43,6 +44,10 @@ OPTIONS
When creating files, prepend <string> (usually a directory
including a trailing /)
+--suffix=<string>::
+ When creating files, append <string> to the name. The value
+ of <string> must not contain a directory separator (/).
+
--stage=<number>::
Instead of checking out unmerged entries, copy out the
files from named stage. <number> must be between 1 and 3.
@@ -120,6 +125,28 @@ $ git-checkout-index --prefix=.merged- M
This will check out the currently cached copy of `Makefile`
into the file `.merged-Makefile`.
+Export files with a suffix::
++
+----------------
+$ git-checkout-index --suffix=\#2 --stage=2 Makefile
+----------------
++
+If `Makefile` is unmerged and has a stage 2 entry in the index
+this will check out that version into the file `Makefile#2`.
+
+A suffix may be preferred over a prefix when checking out all
+unmerged entries:
++
+----------------
+$ git-checkout-index --suffix=\#1 --stage=1 --all
+$ git-checkout-index --suffix=\#2 --stage=2 --all
+$ git-checkout-index --suffix=\#3 --stage=3 --all
+----------------
++
+would unpack all unmerged stages into the same directory as the
+tracked file. (Compare with --prefix=.stage1/ which would have
+created a partial directory tree within `.stage1/`.)
+
Author
------
diff --git a/apply.c b/apply.c
index 244718c..1ec8473 100644
--- a/apply.c
+++ b/apply.c
@@ -1307,6 +1307,8 @@ static int check_patch(struct patch *pat
/* checkout */
costate.base_dir = "";
costate.base_dir_len = 0;
+ costate.name_suffix = "";
+ costate.name_suffix_len = 0;
costate.force = 0;
costate.quiet = 0;
costate.not_new = 0;
diff --git a/cache.h b/cache.h
index 58eec00..055e213 100644
--- a/cache.h
+++ b/cache.h
@@ -254,6 +254,8 @@ extern const char *git_committer_info(in
struct checkout {
const char *base_dir;
int base_dir_len;
+ const char *name_suffix;
+ int name_suffix_len;
unsigned force:1,
quiet:1,
not_new:1,
diff --git a/checkout-index.c b/checkout-index.c
index f54c606..af7b230 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -47,6 +47,8 @@ static int checkout_stage; /* default to
static struct checkout state = {
.base_dir = "",
.base_dir_len = 0,
+ .name_suffix = "",
+ .name_suffix_len = 0,
.force = 0,
.quiet = 0,
.not_new = 0,
@@ -180,6 +182,14 @@ int main(int argc, char **argv)
state.base_dir_len = strlen(state.base_dir);
continue;
}
+ if (!strncmp(arg, "--suffix=", 9)) {
+ if (strchr(arg+9, '/')) {
+ die("--suffix cannot contain /");
+ }
+ state.name_suffix = arg+9;
+ state.name_suffix_len = strlen(state.name_suffix);
+ continue;
+ }
if (!strncmp(arg, "--stage=", 8)) {
int ch = arg[8];
if ('1' <= ch && ch <= '3')
@@ -193,8 +203,8 @@ int main(int argc, char **argv)
break;
}
- if (state.base_dir_len) {
- /* when --prefix is specified we do not
+ if (state.base_dir_len || state.name_suffix_len) {
+ /* when --prefix or --suffix is specified we do not
* want to update cache.
*/
if (state.refresh_cache) {
diff --git a/entry.c b/entry.c
index 8fb99bc..dc35a07 100644
--- a/entry.c
+++ b/entry.c
@@ -117,10 +117,14 @@ int checkout_entry(struct cache_entry *c
{
struct stat st;
static char path[MAXPATHLEN+1];
- int len = state->base_dir_len;
+ int len1 = state->base_dir_len;
+ int len2 = strlen(ce->name);
+ int len3 = state->name_suffix_len;
+ char *path_len1 = path + len1;
- memcpy(path, state->base_dir, len);
- strcpy(path + len, ce->name);
+ memcpy(path, state->base_dir, len1);
+ memcpy(path_len1, ce->name, len2 + 1);
+ memcpy(path_len1 + len2, state->name_suffix, len3 + 1);
if (!lstat(path, &st)) {
unsigned changed = ce_match_stat(ce, &st, 1);
diff --git a/read-tree.c b/read-tree.c
index f39fe5c..f223a0d 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -281,6 +281,7 @@ static void check_updates(struct cache_e
{
static struct checkout state = {
.base_dir = "",
+ .name_suffix = "",
.force = 1,
.quiet = 1,
.refresh_cache = 1,
--
1.2.3.gdf23c-dirty
^ permalink raw reply related
* [PATCH] Teach git-checkout-index to read filenames from stdin.
From: Shawn Pearce @ 2006-03-01 2:43 UTC (permalink / raw)
To: git
Since git-checkout-index is often used from scripts which
may have a stream of filenames they wish to checkout it is
more convenient to use --stdin than xargs. On platforms
where fork performance is currently sub-optimal and
the length of a command line is limited (*cough* Cygwin
*cough*) running a single git-checkout-index process for
a large number of files beats spawning it multiple times
from xargs.
File names are still accepted on the command line if
--stdin is not supplied. Nothing is performed if no files
are supplied on the command line or by stdin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I wonder if Linus will stop using
find ... -print0 | xargs -0 git-checkout-index --
with this option available.
Eh, probably not as xargs requires less typing than -z --stdin.
Documentation/git-checkout-index.txt | 20 +++++++++++++++--
checkout-index.c | 41 ++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+), 2 deletions(-)
base 84434f9549d56e522a2eb4de370100f0a6e5e041
last df23c1119d0af1fbac6b8afd296113e155d9a878
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 2a1e526..b0b6588 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -10,7 +10,9 @@ SYNOPSIS
--------
[verse]
'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
- [--stage=<number>] [--] <file>...
+ [--stage=<number>]
+ [-z] [--stdin]
+ [--] [<file>]\*
DESCRIPTION
-----------
@@ -45,6 +47,15 @@ OPTIONS
Instead of checking out unmerged entries, copy out the
files from named stage. <number> must be between 1 and 3.
+--stdin::
+ Instead of taking list of paths from the command line,
+ read list of paths from the standard input. Paths are
+ separated by LF (i.e. one path per line) by default.
+
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
--::
Do not interpret any more arguments as options.
@@ -64,7 +75,12 @@ $ find . -name '*.h' -print0 | xargs -0
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
-force-refresh everything in the index, which was not the point.
+force-refresh everything in the index, which was not the point. But
+since git-checkout-index accepts --stdin it would be faster to use:
+
+----------------
+$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
+----------------
The `--` is just a good idea when you know the rest will be filenames;
it will prevent problems with a filename of, for example, `-a`.
diff --git a/checkout-index.c b/checkout-index.c
index 957b4a8..f54c606 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -22,6 +22,10 @@
*
* find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
*
+ * or:
+ *
+ * find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
+ *
* which will force all existing *.h files to be replaced with
* their cached copies. If an empty command line implied "all",
* then this would force-refresh everything in the cache, which
@@ -33,6 +37,8 @@
* but get used to it in scripting!).
*/
#include "cache.h"
+#include "strbuf.h"
+#include "quote.h"
static const char *prefix;
static int prefix_length;
@@ -114,6 +120,8 @@ int main(int argc, char **argv)
int i;
int newfd = -1;
int all = 0;
+ int read_from_stdin = 0;
+ int line_termination = '\n';
prefix = setup_git_directory();
git_config(git_default_config);
@@ -156,6 +164,17 @@ int main(int argc, char **argv)
die("cannot open index.lock file.");
continue;
}
+ if (!strcmp(arg, "-z")) {
+ line_termination = 0;
+ continue;
+ }
+ if (!strcmp(arg, "--stdin")) {
+ if (i != argc - 1)
+ die("--stdin must be at the end");
+ read_from_stdin = 1;
+ i++; /* do not consider arg as a file name */
+ break;
+ }
if (!strncmp(arg, "--prefix=", 9)) {
state.base_dir = arg+9;
state.base_dir_len = strlen(state.base_dir);
@@ -191,9 +210,31 @@ int main(int argc, char **argv)
if (all)
die("git-checkout-index: don't mix '--all' and explicit filenames");
+ if (read_from_stdin)
+ die("git-checkout-index: don't mix '--stdin' and explicit filenames");
checkout_file(prefix_path(prefix, prefix_length, arg));
}
+ if (read_from_stdin) {
+ struct strbuf buf;
+ if (all)
+ die("git-checkout-index: don't mix '--all' and '--stdin'");
+ strbuf_init(&buf);
+ while (1) {
+ char *path_name;
+ read_line(&buf, stdin, line_termination);
+ if (buf.eof)
+ break;
+ if (line_termination && buf.buf[0] == '"')
+ path_name = unquote_c_style(buf.buf, NULL);
+ else
+ path_name = buf.buf;
+ checkout_file(prefix_path(prefix, prefix_length, path_name));
+ if (path_name != buf.buf)
+ free(path_name);
+ }
+ }
+
if (all)
checkout_all();
--
1.2.3.gdf23c
^ permalink raw reply related
* Re: Quick question: end of lines
From: Emmanuel Guerin @ 2006-03-01 0:12 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90602281215n259066b1qe2e6421625b82e75@mail.gmail.com>
2006/3/1, Martin Langhoff <martin.langhoff@gmail.com>:
> Why is this important?
>
> (I am thinking: any reasonably good text editor will know how to deal
> with unix newlines, but you may have different reasons).
Actually, you have found the problem. My particular setup is that
Visual Studio is used on Windows. The editor will handle unix end of
lines all right, but tends to insert windows ones when modifications
are made. This leads to files with inconsistent end of lines, and
nightmares with merges. We use Subversion for the moment, and we have
to make sure that all text files are declared properly in svn to avoid
conflicts.
What I begin to realize is that the only possibility probably lies in
using a tool that converts the modified files "on the fly" before
commits. I just want to make sure that no other solution was found by
others facing a similar problem.
Anyway, thanks for the answers,
Emmanuel
^ permalink raw reply
* Re: [PATCH 3/3] Tie it all together: "git log"
From: Martin Langhoff @ 2006-02-28 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vr75nm8cl.fsf@assigned-by-dhcp.cox.net>
On 3/1/06, Junio C Hamano <junkio@cox.net> wrote:
> I would say we should just rip merge-order out. Who uses it,
> and why does it not work with topo-order, again?
IIRC archimport uses it, but there's no reason why topo-order wouldn't work.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 3/3] Tie it all together: "git log"
From: Linus Torvalds @ 2006-02-28 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr75nm8cl.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Feb 2006, Junio C Hamano wrote:
>
> I would say we should just rip merge-order out. Who uses it,
> and why does it not work with topo-order, again?
Well, assuming breaking --merge-order is fine, here's a patch (on top of
the other ones) that makes
git log <filename>
actually work, as far as I can tell.
I didn't add the logic for --before/--after flags, but that should be
pretty trivial, and is independent of this anyway.
Perhaps more importantly, I didn't remove the tests that now start
failing, nor did I remove the actual code to do --merge-order ;/
Linus
----
diff --git a/rev-list.c b/rev-list.c
index 94f22dd..6993b1a 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -8,10 +8,9 @@
#include "diff.h"
#include "revision.h"
-/* bits #0-2 in revision.h */
+/* bits #0-3 in revision.h */
-#define COUNTED (1u << 3)
-#define SHOWN (1u << 4)
+#define COUNTED (1u << 4)
#define TMP_MARK (1u << 5) /* for isolated cases; clean after use */
static const char rev_list_usage[] =
@@ -25,7 +24,6 @@ static const char rev_list_usage[] =
" --remove-empty\n"
" --all\n"
" ordering output:\n"
-" --merge-order [ --show-breaks ]\n"
" --topo-order\n"
" --date-order\n"
" formatting output:\n"
@@ -47,22 +45,9 @@ static int show_parents = 0;
static int hdr_termination = 0;
static const char *commit_prefix = "";
static enum cmit_fmt commit_format = CMIT_FMT_RAW;
-static int merge_order = 0;
-static int show_breaks = 0;
-static int stop_traversal = 0;
-static int no_merges = 0;
static void show_commit(struct commit *commit)
{
- commit->object.flags |= SHOWN;
- if (show_breaks) {
- commit_prefix = "| ";
- if (commit->object.flags & DISCONTINUITY) {
- commit_prefix = "^ ";
- } else if (commit->object.flags & BOUNDARY) {
- commit_prefix = "= ";
- }
- }
printf("%s%s", commit_prefix, sha1_to_hex(commit->object.sha1));
if (show_parents) {
struct commit_list *parents = commit->parents;
@@ -96,73 +81,6 @@ static void show_commit(struct commit *c
fflush(stdout);
}
-static int rewrite_one(struct commit **pp)
-{
- for (;;) {
- struct commit *p = *pp;
- if (p->object.flags & (TREECHANGE | UNINTERESTING))
- return 0;
- if (!p->parents)
- return -1;
- *pp = p->parents->item;
- }
-}
-
-static void rewrite_parents(struct commit *commit)
-{
- struct commit_list **pp = &commit->parents;
- while (*pp) {
- struct commit_list *parent = *pp;
- if (rewrite_one(&parent->item) < 0) {
- *pp = parent->next;
- continue;
- }
- pp = &parent->next;
- }
-}
-
-static int filter_commit(struct commit * commit)
-{
- if (stop_traversal && (commit->object.flags & BOUNDARY))
- return STOP;
- if (commit->object.flags & (UNINTERESTING|SHOWN))
- return CONTINUE;
- if (revs.min_age != -1 && (commit->date > revs.min_age))
- return CONTINUE;
- if (revs.max_age != -1 && (commit->date < revs.max_age)) {
- stop_traversal=1;
- return CONTINUE;
- }
- if (no_merges && (commit->parents && commit->parents->next))
- return CONTINUE;
- if (revs.paths && revs.dense) {
- if (!(commit->object.flags & TREECHANGE))
- return CONTINUE;
- rewrite_parents(commit);
- }
- return DO;
-}
-
-static int process_commit(struct commit * commit)
-{
- int action=filter_commit(commit);
-
- if (action == STOP) {
- return STOP;
- }
-
- if (action == CONTINUE) {
- return CONTINUE;
- }
-
- if (revs.max_count != -1 && !revs.max_count--)
- return STOP;
-
- show_commit(commit);
-
- return CONTINUE;
-}
-
static struct object_list **process_blob(struct blob *blob,
struct object_list **p,
struct name_path *path,
@@ -219,8 +137,7 @@ static void show_commit_list(struct rev_
while ((commit = get_revision(revs)) != NULL) {
p = process_tree(commit->tree, p, NULL, "");
- if (process_commit(commit) == STOP)
- break;
+ show_commit(commit);
}
for (pending = revs->pending_objects; pending; pending = pending->next) {
struct object *obj = pending->item;
@@ -416,10 +333,6 @@ int main(int argc, const char **argv)
commit_prefix = "commit ";
continue;
}
- if (!strncmp(arg, "--no-merges", 11)) {
- no_merges = 1;
- continue;
- }
if (!strcmp(arg, "--parents")) {
show_parents = 1;
continue;
@@ -428,14 +341,6 @@ int main(int argc, const char **argv)
bisect_list = 1;
continue;
}
- if (!strcmp(arg, "--merge-order")) {
- merge_order = 1;
- continue;
- }
- if (!strcmp(arg, "--show-breaks")) {
- show_breaks = 1;
- continue;
- }
usage(rev_list_usage);
}
@@ -456,17 +361,7 @@ int main(int argc, const char **argv)
save_commit_buffer = verbose_header;
track_object_refs = 0;
- if (!merge_order) {
- show_commit_list(&revs);
- } else {
-#ifndef NO_OPENSSL
- if (sort_list_in_merge_order(list, &process_commit)) {
- die("merge order sort failed\n");
- }
-#else
- die("merge order sort unsupported, OpenSSL not linked");
-#endif
- }
+ show_commit_list(&revs);
return 0;
}
diff --git a/revision.c b/revision.c
index fb728c1..f98fae9 100644
--- a/revision.c
+++ b/revision.c
@@ -381,6 +381,9 @@ static void limit_list(struct rev_info *
struct commit_list *newlist = NULL;
struct commit_list **p = &newlist;
+ if (revs->paths)
+ diff_tree_setup_paths(revs->paths);
+
while (list) {
struct commit_list *entry = list;
struct commit *commit = list->item;
@@ -436,12 +439,13 @@ static void handle_all(struct rev_info *
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
*
- * Returns the number of arguments left ("new argc").
+ * Returns the number of arguments left that weren't recognized
+ * (which are also moved to the head of the argument list)
*/
int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def)
{
int i, flags, seen_dashdash;
- const char **unrecognized = argv+1;
+ const char **unrecognized = argv + 1;
int left = 1;
memset(revs, 0, sizeof(*revs));
@@ -525,6 +529,10 @@ int setup_revisions(int argc, const char
revs->remove_empty_trees = 1;
continue;
}
+ if (!strncmp(arg, "--no-merges", 11)) {
+ revs->no_merges = 1;
+ continue;
+ }
if (!strcmp(arg, "--objects")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
@@ -601,14 +609,11 @@ int setup_revisions(int argc, const char
}
if (revs->paths)
revs->limited = 1;
- *unrecognized = NULL;
return left;
}
void prepare_revision_walk(struct rev_info *revs)
{
- if (revs->paths)
- diff_tree_setup_paths(revs->paths);
sort_by_date(&revs->commits);
if (revs->limited)
limit_list(revs);
@@ -616,11 +621,67 @@ void prepare_revision_walk(struct rev_in
sort_in_topological_order(&revs->commits, revs->lifo);
}
+static int rewrite_one(struct commit **pp)
+{
+ for (;;) {
+ struct commit *p = *pp;
+ if (p->object.flags & (TREECHANGE | UNINTERESTING))
+ return 0;
+ if (!p->parents)
+ return -1;
+ *pp = p->parents->item;
+ }
+}
+
+static void rewrite_parents(struct commit *commit)
+{
+ struct commit_list **pp = &commit->parents;
+ while (*pp) {
+ struct commit_list *parent = *pp;
+ if (rewrite_one(&parent->item) < 0) {
+ *pp = parent->next;
+ continue;
+ }
+ pp = &parent->next;
+ }
+}
+
struct commit *get_revision(struct rev_info *revs)
{
- if (!revs->commits)
+ struct commit_list *list = revs->commits;
+ struct commit *commit;
+
+ if (!list)
return NULL;
- return pop_most_recent_commit(&revs->commits, SEEN);
-}
+ /* Check the max_count ... */
+ commit = list->item;
+ switch (revs->max_count) {
+ case -1:
+ break;
+ case 0:
+ return NULL;
+ default:
+ revs->max_count--;
+ }
+ do {
+ commit = pop_most_recent_commit(&revs->commits, SEEN);
+ if (commit->object.flags & (UNINTERESTING|SHOWN))
+ continue;
+ if (revs->min_age != -1 && (commit->date > revs->min_age))
+ continue;
+ if (revs->max_age != -1 && (commit->date < revs->max_age))
+ return NULL;
+ if (revs->no_merges && commit->parents && commit->parents->next)
+ continue;
+ if (revs->paths && revs->dense) {
+ if (!(commit->object.flags & TREECHANGE))
+ continue;
+ rewrite_parents(commit);
+ }
+ commit->object.flags |= SHOWN;
+ return commit;
+ } while (revs->commits);
+ return NULL;
+}
diff --git a/revision.h b/revision.h
index 0bed3c0..0043c16 100644
--- a/revision.h
+++ b/revision.h
@@ -4,6 +4,7 @@
#define SEEN (1u<<0)
#define UNINTERESTING (1u<<1)
#define TREECHANGE (1u<<2)
+#define SHOWN (1u<<3)
struct rev_info {
/* Starting list */
@@ -16,6 +17,7 @@ struct rev_info {
/* Traversal flags */
unsigned int dense:1,
+ no_merges:1,
remove_empty_trees:1,
lifo:1,
topo_order:1,
^ permalink raw reply related
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-02-28 22:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <44037A5C.6080409@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
On 27/02/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> An idea (untested, I don't even know whether it's feasible) would be to
> check which patches were merged by reverse-applying them starting with
> the last. In this situation, all the merged patches should just revert
> their changes. You only need to do a git-diff between the bottom and the
> top of the patch and git-apply the output (maybe without even modifying
> the tree). If this operation succeeds, the patch was integrated and you
> don't even need to push it.
I attached another patch that should work properly. It also pushes
empty patches on the stack if they were merged upstream (a 'stg clean'
is required to remove them). This is useful for the push --undo
command if you are not happy with the result.
I'll try this patch for a bit more before pushing into the repository.
--
Catalin
[-- Attachment #2: merged-test.diff --]
[-- Type: text/x-patch, Size: 8706 bytes --]
Add a merged upstream test for pull and push
From: Catalin Marinas <catalin.marinas@gmail.com>
This patch adds the --merged option to both pull and push commands. With
this option, these commands will first try to check which patches were
merged upstream by reverse-applying them in reverse order. This should
solve the situation where several patches modify the same line in a file.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/common.py | 41 +++++++++++++++++++++++++++++++++++++++++
stgit/commands/pull.py | 15 +++++----------
stgit/commands/push.py | 28 ++++++----------------------
stgit/git.py | 12 +++++++++---
stgit/stack.py | 34 +++++++++++++++++++++++++++++++---
5 files changed, 92 insertions(+), 38 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 2e1ba7a..2985379 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -132,6 +132,47 @@ def resolved_all(reset = None):
resolved(filename, reset)
os.remove(os.path.join(git.get_base_dir(), 'conflicts'))
+def push_patches(patches, check_merged = False):
+ """Push multiple patches onto the stack. This function is shared
+ between the push and pull commands
+ """
+ forwarded = crt_series.forward_patches(patches)
+ if forwarded > 1:
+ print 'Fast-forwarded patches "%s" - "%s"' % (patches[0],
+ patches[forwarded - 1])
+ elif forwarded == 1:
+ print 'Fast-forwarded patch "%s"' % patches[0]
+
+ names = patches[forwarded:]
+
+ # check for patches merged upstream
+ if check_merged:
+ print 'Checking for patches merged upstream...',
+ sys.stdout.flush()
+
+ merged = crt_series.merged_patches(names)
+
+ print 'done (%d found)' % len(merged)
+ else:
+ merged = []
+
+ for p in names:
+ print 'Pushing patch "%s"...' % p,
+ sys.stdout.flush()
+
+ if p in merged:
+ crt_series.push_patch(p, empty = True)
+ print 'done (merged upstream)'
+ else:
+ modified = crt_series.push_patch(p)
+
+ if crt_series.empty_patch(p):
+ print 'done (empty patch)'
+ elif modified:
+ print 'done (modified)'
+ else:
+ print 'done'
+
def name_email(address):
"""Return a tuple consisting of the name and email parsed from a
standard 'name <email>' string
diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 843b579..8f26f4d 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -39,6 +39,9 @@ format."""
options = [make_option('-n', '--nopush',
help = 'do not push the patches back after pulling',
+ action = 'store_true'),
+ make_option('-m', '--merged',
+ help = 'check for patches merged upstream',
action = 'store_true')]
def func(parser, options, args):
@@ -75,15 +78,7 @@ def func(parser, options, args):
print 'done'
# push the patches back
- if options.nopush:
- applied = []
- for p in applied:
- print 'Pushing patch "%s"...' % p,
- sys.stdout.flush()
- crt_series.push_patch(p)
- if crt_series.empty_patch(p):
- print 'done (empty patch)'
- else:
- print 'done'
+ if not options.nopush:
+ push_patches(applied, options.merged)
print_crt_patch()
diff --git a/stgit/commands/push.py b/stgit/commands/push.py
index 9924a78..90777c1 100644
--- a/stgit/commands/push.py
+++ b/stgit/commands/push.py
@@ -49,6 +49,9 @@ options = [make_option('-a', '--all',
make_option('--reverse',
help = 'push the patches in reverse order',
action = 'store_true'),
+ make_option('-m', '--merged',
+ help = 'check for patches merged upstream',
+ action = 'store_true'),
make_option('--undo',
help = 'undo the last push operation',
action = 'store_true')]
@@ -58,9 +61,9 @@ def is_patch_appliable(p):
"""See if patch exists, or is already applied.
"""
if p in applied:
- raise CmdException, 'Patch "%s" is already applied.' % p
+ raise CmdException, 'Patch "%s" is already applied' % p
if p not in unapplied:
- raise CmdException, 'Patch "%s" does not exist.' % p
+ raise CmdException, 'Patch "%s" does not exist' % p
def func(parser, options, args):
"""Pushes the given patch or all onto the series
@@ -127,25 +130,6 @@ def func(parser, options, args):
if options.reverse:
patches.reverse()
- forwarded = crt_series.forward_patches(patches)
- if forwarded > 1:
- print 'Fast-forwarded patches "%s" - "%s"' % (patches[0],
- patches[forwarded - 1])
- elif forwarded == 1:
- print 'Fast-forwarded patch "%s"' % patches[0]
-
- for p in patches[forwarded:]:
- is_patch_appliable(p)
-
- print 'Pushing patch "%s"...' % p,
- sys.stdout.flush()
+ push_patches(patches, options.merged)
- modified = crt_series.push_patch(p)
-
- if crt_series.empty_patch(p):
- print 'done (empty patch)'
- elif modified:
- print 'done (modified)'
- else:
- print 'done'
print_crt_patch()
diff --git a/stgit/git.py b/stgit/git.py
index a3488ff..40d54ef 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -465,14 +465,20 @@ def commit(message, files = None, parent
return commit_id
-def apply_diff(rev1, rev2):
+def apply_diff(rev1, rev2, check_index = True):
"""Apply the diff between rev1 and rev2 onto the current
index. This function doesn't need to raise an exception since it
is only used for fast-pushing a patch. If this operation fails,
the pushing would fall back to the three-way merge.
"""
- return os.system('git-diff-tree -p %s %s | git-apply --index 2> /dev/null'
- % (rev1, rev2)) == 0
+ if check_index:
+ index_opt = '--index'
+ else:
+ index_opt = ''
+ cmd = 'git-diff-tree -p %s %s | git-apply %s 2> /dev/null' \
+ % (rev1, rev2, index_opt)
+
+ return os.system(cmd) == 0
def merge(base, head1, head2):
"""Perform a 3-way merge between base, head1 and head2 into the
diff --git a/stgit/stack.py b/stgit/stack.py
index e1c55f0..165b5a7 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -780,7 +780,27 @@ class Series:
return forwarded
- def push_patch(self, name):
+ def merged_patches(self, names):
+ """Test which patches were merged upstream by reverse-applying
+ them in reverse order. The function returns the list of
+ patches detected to have been applied. The state of the tree
+ is restored to the original one
+ """
+ patches = [Patch(name, self.__patch_dir, self.__refs_dir)
+ for name in names]
+ patches.reverse()
+
+ merged = []
+ for p in patches:
+ if git.apply_diff(p.get_top(), p.get_bottom(), False):
+ merged.append(p.get_name())
+ merged.reverse()
+
+ git.reset()
+
+ return merged
+
+ def push_patch(self, name, empty = False):
"""Pushes a patch on the stack
"""
unapplied = self.get_unapplied()
@@ -798,7 +818,15 @@ class Series:
modified = False
# top != bottom always since we have a commit for each patch
- if head == bottom:
+ if empty:
+ # just make an empty patch (top = bottom = HEAD). This
+ # option is useful to allow undoing already merged
+ # patches. The top is updated by refresh_patch since we
+ # need an empty commit
+ patch.set_bottom(head, backup = True)
+ patch.set_top(head, backup = True)
+ modified = True
+ elif head == bottom:
# reset the backup information
patch.set_bottom(bottom, backup = True)
patch.set_top(top, backup = True)
@@ -835,7 +863,7 @@ class Series:
self.__set_current(name)
# head == bottom case doesn't need to refresh the patch
- if head != bottom:
+ if empty or head != bottom:
if not ex:
# if the merge was OK and no conflicts, just refresh the patch
# The GIT cache was already updated by the merge operation
^ permalink raw reply related
* Re: [PATCH 3/3] Tie it all together: "git log"
From: Junio C Hamano @ 2006-02-28 22:22 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0602281251390.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Anyway, apart from that issue (which I think should be trivial to sort out
> if we accept breaking --merge-order), the rest looks like it should just
> get more testing and handling of the few missing flags from rev-parse in
> revision.c, and it should be good.
I would say we should just rip merge-order out. Who uses it,
and why does it not work with topo-order, again?
^ permalink raw reply
* [PATCH] Warn about invalid refs
From: Johannes Schindelin @ 2006-02-28 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe5a1yft.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Thu, 27 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 27 Oct 2005, Junio C Hamano wrote:
> >
> >> Not that the current loop is any better for that purpose.
> >> We silently ignore not just dangling ref and ref not storing
> >> 40-byte hex, but files starting with a period '.', names
> >> longer than 255 bytes, and unreadable ones, all of which we
> >> would probably want to warn about in such a tool.
> >
> > Okay, how about 'fprintf(stderr, "Warning: ...\n"); continue;'
> > instead of 'die("...");' then?
>
> Yup. That sounds sensible.
Sorry for taking so long...
refs.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 826ae7a..982ebf8 100644
--- a/refs.c
+++ b/refs.c
@@ -151,10 +151,15 @@ static int do_for_each_ref(const char *b
break;
continue;
}
- if (read_ref(git_path("%s", path), sha1) < 0)
+ if (read_ref(git_path("%s", path), sha1) < 0) {
+ fprintf(stderr, "%s points nowhere!", path);
continue;
- if (!has_sha1_file(sha1))
+ }
+ if (!has_sha1_file(sha1)) {
+ fprintf(stderr, "%s does not point to a valid "
+ "commit object!", path);
continue;
+ }
retval = fn(path, sha1);
if (retval)
break;
^ permalink raw reply related
* Re: [PATCH 3/3] Tie it all together: "git log"
From: Linus Torvalds @ 2006-02-28 20:59 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602281126340.22647@g5.osdl.org>
On Tue, 28 Feb 2006, Linus Torvalds wrote:
>
> Again, this may not do exactly what the current "git log" does. That's not
> the point. The point is to introduce the fundamental functionality, so
> that people can play with this and improve on it, and fix any of my stupid
> bugs.
Btw, before anybody even pipes up: the missing piece here is the nasty
"filter_commit()" that rev-list.c does, and that really should be moved
into revision.c, and this is where I hit on the "--merge-order" issues.
So for example, if you do "git log -- <filename>" with the new git, it
won't filter out the commits that just change the passed-in <filename>
properly, because the filtering code still exists only in git-rev-list
(even if revision.c now does the traversal).
Same goes for the max-count-based filtering, for the same reason.
So the "process_commit()" handling should be moved into "get_revision()",
but since the merge-order code also hooks into it...
Anyway, apart from that issue (which I think should be trivial to sort out
if we accept breaking --merge-order), the rest looks like it should just
get more testing and handling of the few missing flags from rev-parse in
revision.c, and it should be good.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] quilt2git v0.2
From: Sam Vilain @ 2006-02-28 20:55 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, git
In-Reply-To: <20060228111115.GA32276@htj.dyndns.org>
Tejun Heo wrote:
> Hello, v0.2 of quilt2git available. New in v0.2.
>
> * handles new git HEAD file format properly (regular file storing ref: ...)
>
> * makes use of mail format header from quilt patch description. From:
> becomes the author, Subject: the subject of the patch. All commit
> information should be maintained through git2quilt -> quilt2git now.
>
> * --signoff option added. This option is simply passed to git-commit.
>
> * little fixes
>
> http://home-tj.org/wiki/index.php/Misc
> http://home-tj.org/files/misc/quilt2git-0.2
> http://home-tj.org/files/misc/git2quilt-0.1
>
> Thanks.
>
FWIW, I have a similar script to import a quilt export as an stgit patch
series, it's really simple but quite useful:
http://vserver.ustl.gen.nz/scripts/import-quilt
Sam.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox