* Re: [RFC/PATCH 3/7] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Christian Couder @ 2009-01-15 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200901151044.45967.chriscool@tuxfamily.org>
Le jeudi 15 janvier 2009, Christian Couder a écrit :
> Le mardi 13 janvier 2009, Junio C Hamano a écrit :
>
> > Since your paradigm is prepare replacement once at the beginning, never
> > allowing to update it, I think you can update the table while you look
> > it up. E.g. if A->B and B->C exists, and A is asked for, you find A->B
> > (to tentatively make cur to point at B) and then you find B->C, and
> > before returning you can rewrite the first mapping to A->C. Later
> > look-up won't need to dereference the table twice that way.
> >
> > This assumes that there will be small number of replacements, but the
> > same object can be asked for more than once during the process.
>
> If we allow different sets of replace refs, for example A->B
> in "refs/replace/" and B->C in "refs/replace/bisect/", then we cannot
> rewrite as you suggest. We could add A->C in "refs/replace/bisect/", so
> that it overcomes A->B and B->C when we bisect, but we would not gain
> much.
Sorry, I just realized I misunderstood what you said. I don't know why but I
thought you talked about updating the refs. But in fact you are right it
should be possible to update the "replace_object" table.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Junio C Hamano @ 2009-01-15 18:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Teemu Likonen, Thomas Rast, git, Santi Béjar
In-Reply-To: <alpine.DEB.1.00.0901151337080.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW this gets even worse when you compare the following:
>
> bbb aaa
> ccc aaa
>
> --color-words=a+ will show
>
> ccc aaa
Naive question. What is the expected output?
The user defines that "a", "aa", "aaa",... are words and everything else
is the background that the words float on, and asks --color-words to color
code where the words differ. The way to show them is to have the words in
red (if it comes from preimage) or in green (if it comes from postimage) on
top of some background.
In this case, there is no difference in words, and the only difference is
the background. Should we still see any output? Shouldn't it behave more
like "diff -w" that suppresses lines that differ only in whitespace?
I didn't see the semantics of color-words documented in the original
either, and I think it should be described in a way humans would
understand (in other words, "here is what we do internally, splitting
words into lines, running diff between them and coalescing the result in
this and that way, and whatever happens to be output is what you get" is
not the semantics that is explained in a way humans would understand).
The above "The way to show them is to have the words in red (if it comes
from preimage) or in green (if it comes from postimage) on top of some
background." was my attempt to describe an easier half of the semantics,
but I am not sure what definition of "some background" the current draft
code is designed around; I think the original's definition was "we discard
the background from either preimage or postimage and insert whitespace
outselves between the words we output; the only exception is the
end-of-line that appears in the postimage which we try to keep" or
something like that, but that is not written in the documentation either.
How should the background computed to draw the result on? If a
corresponding background portion appear in both the preimage and the
postimage, we use the one from the postimage? That justifies why bbb is
not shown but ccc is, when you compare these two:
bbb aaa
ccc aa
What happens if a portion of background is only in the preimage?
E.g. when these two are compared:
bbb aaa bb aa b
ccc aaa cc
what should happen? We would want to say "aa" was removed by showing it
in red, but on what background should it be displayed? cc <red>aa</red>
b?
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 18:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F6AC3.7050704@drmicha.warpmail.net>
Hi,
On Thu, 15 Jan 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 15.01.2009 17:04:
> ...
> >>> The more I think about it, I think it's possible I broke it with the
> >>> introduction of the "noop".
> >> It certainly worked after the noop introduction before the r-i-p series,
> >> but not any more after.
> >
> > Umm... which rebase -i -p series do you mean? "noop" was introduced
> > pretty recently if my Alzheimered brain does not fool me.
>
> This one introduced noop:
>
> commit ff74126c03a8dfd04e7533573a5c420f2a7112ac
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Fri Oct 10 13:42:12 2008 +0200
>
> rebase -i: do not fail when there is no commit to cherry-pick
>
> This is the bad one from bisect:
>
> commit d80d6bc146232d81f1bb4bc58e5d89263fd228d4
> Author: Stephen Haberman <stephen@exigencecorp.com>
> Date: Wed Oct 15 02:44:39 2008 -0500
>
> rebase-i-p: do not include non-first-parent commits touching UPSTREAM
>
> It's the last one in a longer series. And that series is after the noop
> introduction.
Ohhh....
Thanks,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 18:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <7vmydsv72u.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> "Sverre Rabbelier" <srabbelier@gmail.com> writes:
>
> > On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
> >> intuitive).
> >
> > Examine suggests that you cannot change the commit (you can look, but
> > don't touch it!), no?
>
> 'stop' would be closest to what it currently does. It stops and it is up
> to you how to screw up the result ;-).
But it shares the first letter with 'squash'.
Ciao,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 18:22 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901151751580.3586@pacific.mpi-cbg.de>
On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> if you would like me to respond to your questions in the future, it is
> mandatory to keep me in the Cc: list.
OK. [Is that the list convention too?]
> On Thu, 15 Jan 2009, Sitaram Chamarty wrote:
>> I'm unable to make "rebase -p" carry an evil merge over.
>> The "evil" part stays behind.
>>
>> I'm not sure if that is intentional or not, or (more likely)
>> my brain has become addled and I missed something somewhere.
>
> Yes, this is intentional.
>
> Instead of ignoring merges, try to recreate them.
>
> That means it tries to recreate them. Not that it is successful. And not
> even that it realizes when it failed.
Is a conflicted merge that was resolved by making a change
that was in neither parent, an evil merge?
Regardless, I suspect rebase -p will not be able to carry
such a merge over.
But if it won't carry over the evil in an evil merge, what
other uses are there for "rebase -p" as opposed to rebase?
Seems to me that the DAG may be different but the tree you
end up with is the same then.
I'm sure someone has a blog post or a bookmark or an article
or something they wrote long ago about "rebase -i -p".
Anyone?
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 18:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200901151805.44747.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > There are a number of issues why I would like to avoid introducing
> > LAST_HEAD:
> >
> > - it does not work when you are using different Git versions on the same
> > repository,
> >
> > - it does not work when you switched recently,
>
> If you switch once, you'll be able to use the feature one checkout
> later than if it was reflog-based.
>
> If you switch a lot, the feature won't be in your git half the time
> anyway.
But once it is, you could also have something like "git checkout -{5}"
meaning the 5th last branch you were on.
No, I am not married to that syntax
> > - you are storing redundant information,
>
> AFAIK it's the first instance of this data in a non-free-form field.
> There's also the precedent of ORIG_HEAD.
See below.
> > - yes, the field is meant for user consumption, but no, it is not
> > free-form,
>
> It's a field of almost arbitrary character data, filled by 70% of the
> update-ref calls I can find in git.git in a "<tool>: <comment>" format
> and by the rest with things such as "initial pull" or
> "refs/remotes/git-svn: updating HEAD". (The latter is so informative
> that it probably deserves a fix.) How is that not free-form?
That is not free-form, as the "<tool>:" is a hard convention all obey
(and therefore, git checkout - only relies on _checkout_ not changing the
format), and checkout is sufficiently plumbing that we will not change it
all that lightly, certainly not when "git checkout -" depends on it.
So I think that those free-form concerns are totally unfounded.
Oh, and before you say that people could mess with GIT_REFLOG_ACTION, git
checkout is no longer a script, and creates the message itself. So we
have full control over it.
They could edit the logs directly, but that applies to virtually the whole
repository, and can safely be ignored as a lemming behavior.
> > - AFAICT your version could never be convinced to resurrect deleted
> > branches, without resorting to reflogs anyway.
>
> Neither can any other use of git-checkout without the user manually
> recovering some valid revspec referring to the old branch tip from the
> reflog.
To the contrary. The reflog has this information together with the
message "moved from ...".
> > - the reflog method reflects pretty much exactly how people work around
> > the lack of "checkout -" currently, so why not just use the same proven
> > approach?
>
> So you can make me fight an uphill battle against your idea how it
> should be done.
If you can convince me that there are benefits from introducing yet
another file in $GIT_DIR and duplicating information that is in the
reflogs already, then no, it's not an uphill battle.
I mean, I _like_ the feature. Otherwise I would not spend so much time
suggesting what I think would be a method more in line with what we have
already.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-15 18:46 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt, Anders Melchiorsen
In-Reply-To: <alpine.DEB.1.00.0901151921040.3586@pacific.mpi-cbg.de>
On Thursday 15 January 2009, Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
> > 'stop' would be closest to what it currently does. It stops and it
> > is up to you how to screw up the result ;-).
>
> But it shares the first letter with 'squash'.
Personally, I'd rather use "pause", but that is taken as well.
Other suggestions:
wait
yield
rest
timeout
..Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Anders Melchiorsen @ 2009-01-15 18:53 UTC (permalink / raw)
To: Johan Herland
Cc: git, Johannes Schindelin, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <200901151946.04991.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Thursday 15 January 2009, Johannes Schindelin wrote:
>> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>> > 'stop' would be closest to what it currently does. It stops and it
>> > is up to you how to screw up the result ;-).
>>
>> But it shares the first letter with 'squash'.
>
> Personally, I'd rather use "pause", but that is taken as well.
>
> Other suggestions:
>
> wait
> yield
> rest
> timeout
break
Anders.
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-15 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Teemu Likonen, Thomas Rast, git, Santi Béjar
In-Reply-To: <7vmydstoys.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> I didn't see the semantics of color-words documented in the original
> either,
Yeah, my bad. Will try to fix it with this round of patches.
Actually, I'll give a quick outline right here:
Idea: the idea of word diff is to show the differences on a word level
instead of line level. To make it easier for humans (albeit we studiously
exclude color blinds with our defaults), we do not show "+" and "-" as the
standard diff does, but use colors to designate if the words were removed
or added.
Now, the thing is that the inter-word parts _can_ differ. The idea here
is to show the part of the postimage and drop the preimage under the
table.
Method: We use libxdiff as the real workhorse. First, we let it generate
a line diff.
Then we reconstruct the preimage and postimage for each hunk, process both
into new images that have at most one word (in the new code exactly one
word) per line, and feed the new preimage/postimage pair to libxdiff.
>From the output of libxdiff, we reconstruct which words were actually
removed and which were added. Then -- like the line based diff -- we
combine the runs of common words, removed words and added words, and show
them.
The algorithm I implemented in the new patch series is actually much
cleaner than the old one:
- it feeds images to libxdiff which contain _exactly_ one word per line,
decoupling the word offsets in the original image from the offsets in
the processed image,
- this decoupling allows for arbitrary word boundaries, even 0-character
ones,
- it parses the hunk headers of the libxdiff output instead of the "-",
"+" and " " lines, and therefore does not have to play tricks with the
newline character in the middle of a run of removed words.
> What happens if a portion of background is only in the preimage?
If it is in a run of words that were removed, i.e. that are only in the
preimage, then it is shown in that part. Otherwise, the background of the
preimage is never shown.
> E.g. when these two are compared:
>
> bbb aaa bb aa b
> ccc aaa cc
>
> what should happen? We would want to say "aa" was removed by showing it
> in red, but on what background should it be displayed? cc <red>aa</red>
> b?
If we are only ever interested in the 'a's, I'd say that the output should
only reflect that. In other words, what the current code does (ccc
aaa<red>aa</red> cc) is okay IMHO. After all, we said we're interested in
the 'a's, so we should not complain that it did not show us the removal of
'b's.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 19:28 UTC (permalink / raw)
To: Anders Melchiorsen
Cc: Johan Herland, git, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <87ocy8flka.fsf@cup.kalibalik.dk>
Hi,
On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
> break
As rebase -i is just a loop of cherry-picks, as a C programmer I would
think: "does this break out of the loop"?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Wincent Colaiuta @ 2009-01-15 19:27 UTC (permalink / raw)
To: Johan Herland
Cc: git, Johannes Schindelin, Junio C Hamano, Sverre Rabbelier,
Johannes Sixt, Anders Melchiorsen
In-Reply-To: <200901151946.04991.johan@herland.net>
El 15/1/2009, a las 19:46, Johan Herland escribió:
> On Thursday 15 January 2009, Johannes Schindelin wrote:
>> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>>> 'stop' would be closest to what it currently does. It stops and it
>>> is up to you how to screw up the result ;-).
>>
>> But it shares the first letter with 'squash'.
>
> Personally, I'd rather use "pause", but that is taken as well.
>
> Other suggestions:
>
> wait
> yield
> rest
> timeout
Perhaps stating the obvious, but:
wait - best suggestion so far, seeing as we can't use "stop"
yield - might sound intuitive to a Ruby programmer; but for others
it's probably not so obvious as "yield" has a number of meanings in
normal English similar to "give up", "give over" etc
rest - not quite as good as "wait"; machines wait for humans, but the
never need to rest
timeout - sounds like an error condition, so not really appropriate
Sorry for participating in the painting. Just thought that "wait" was
good enough to merit some positive feedback.
Cheers,
Wincent
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Kirill Smelkov @ 2009-01-15 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmydu3yy7.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 14, 2009 at 03:32:32AM -0800, Junio C Hamano wrote:
[...]
> [Actively cooking]
>
> * gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
> + gitweb: suggest name for OPML view
> + gitweb: don't use pathinfo for global actions
>
> * ks/maint-mailinfo-folded (Mon Jan 12 15:22:11 2009 -0800) 2 commits
> - mailinfo: 'From:' header should be unfold as well
> - mailinfo: correctly handle multiline 'Subject:' header
>
> The author seems to have more updates, but I couldn't extract them from
> the e-mail.
Sorry for the inconvenience, and please pull them all from
git://repo.or.cz/git/kirr.git for-junio
Kirill Smelkov (4):
mailinfo: 'From:' header should be unfold as well
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: correctly handle multiline 'Subject:' header
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Junio C Hamano @ 2009-01-15 20:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <1231978322-21228-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Let git-checkout save the old branch as a symref in LAST_HEAD, and
> make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> the shell.
I do not like this for two reasons.
I will not dispute that you would need to have "checkout" and other branch
switching operations to record where you were in order to be able to refer
to "where I was". And as Dscho and others point out, there already is an
existing mechanism that does exactly that, so it _might_ be easier to work
with an extra LAST_HEAD, it is not absolutely necessary.
I do not see a reason to limit the new notation "where I was" only to "git
checkout". Wouldn't it be handy if you can use the notation as the other
branch to merge from, or the commit to rebase on?
"cd -" is a very good analogy why your "-" shortcut is a short-sighted
convenience feature that is too narrow and not well designed. "cd -" can
go back, but you cannot say "ls -" to list the contents of the previous
directory.
So if this topic were "Introduce LAST_HEAD to always keep track of the
branch I was on before the current branch", and were advertised as "You
can use this throughout git to say things like 'git checkout LAST_HEAD',
'git merge LAST_HEAD', and 'git rebase LAST_HEAD'", I think it might have
made a bit more sense. You could _additionally_ say "because switching to
LAST_HEAD happens very often, there is another short cut 'checkout -' but
that is exactly the same as 'checkout LAST_HEAD'".
Another reason is the one level limitation. If we do not use LAST_HEAD,
and instead used HEAD reflog, to get to this information, there is no
reason we cannot to give an equally easy access to the second from the
last branch the user was on.
So I think it is just the matter of coming up with a clever syntax that
works on reflogs to name the nth last branch we were on and teach that
syntax to both get_sha1() and resolve_ref().
With the attached illustration patch,
$ git checkout junk
$ git chekcout master
$ git checkout @{-1}
will take you back to junk branch. It probably would serve as a starting
point, if anybody is interested.
NOTE!
* It will report "Switched to branch "junk", not "junk (@{-1})" or
anything that hints the user used this new syntax. switch_branches()
may need to be given more information to distinguish the name the end
user spelled to specify the branch (e.g. "@{-1}") and the actual name
of the branch (e.g. "junk"), and use the former together with the
latter when reporting to the end user and use the latter only to record
what happened to the reflog. But this is a very minor point.
* The reflog parser only parses "checkout" and not rebase action. It
also does not notice "git checkout HEAD^" is not switching to a real
branch.
* The code read the reflog twice, first to count how many branch
switching there are and then to locate the N-th entry we are interested
in, because I was lazy. We may want an API to enumerate reflog entries
in reverse.
* interpret_nth_last_branch() is not hooked to get_sha1() codepath in
this patch, so this is still only applicable to "git checkout". But it
should be trivial to do so.
builtin-checkout.c | 10 +++++-
cache.h | 1 +
sha1_name.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+), 2 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index b5dd9c0..a3b69d6 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -361,8 +361,14 @@ struct branch_info {
static void setup_branch_path(struct branch_info *branch)
{
struct strbuf buf = STRBUF_INIT;
- strbuf_addstr(&buf, "refs/heads/");
- strbuf_addstr(&buf, branch->name);
+
+ if (!interpret_nth_last_branch(branch->name, &buf)) {
+ branch->name = xstrdup(buf.buf);
+ strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
+ } else {
+ strbuf_addstr(&buf, "refs/heads/");
+ strbuf_addstr(&buf, branch->name);
+ }
branch->path = strbuf_detach(&buf, NULL);
}
diff --git c/cache.h w/cache.h
index 8e1af26..0dd9168 100644
--- c/cache.h
+++ w/cache.h
@@ -663,6 +663,7 @@ extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *);
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
+extern int interpret_nth_last_branch(const char *str, struct strbuf *);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git c/sha1_name.c w/sha1_name.c
index 159c2ab..6377264 100644
--- c/sha1_name.c
+++ w/sha1_name.c
@@ -674,6 +674,84 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
+struct grab_nth_branch_switch_cbdata {
+ int counting;
+ int nth;
+ struct strbuf *buf;
+};
+
+static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *cb_data)
+{
+ struct grab_nth_branch_switch_cbdata *cb = cb_data;
+ const char *match = NULL;
+
+ if (!prefixcmp(message, "checkout: moving to "))
+ match = message + strlen("checkout: moving to ");
+ else if (!prefixcmp(message, "checkout: moving from ")) {
+ const char *cp = message + strlen("checkout: moving from ");
+ if ((cp = strstr(cp, " to ")) != NULL) {
+ match = cp + 4;
+ }
+ }
+
+ if (!match)
+ return 0;
+
+ if (cb->counting) {
+ cb->nth++;
+ return 0;
+ }
+
+ if (--cb->nth <= 0) {
+ size_t len = strlen(match);
+ while (match[len-1] == '\n')
+ len--;
+ strbuf_reset(cb->buf);
+ strbuf_add(cb->buf, match, len);
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * This reads "@{-N}" syntax, finds the name of the Nth previous
+ * branch we were on, and places the name of the branch in the given
+ * buf and returns 0 if successful.
+ *
+ * If the input is not of the accepted format, it returns a negative
+ * number to signal an error.
+ */
+int interpret_nth_last_branch(const char *name, struct strbuf *buf)
+{
+ int nth, i;
+ struct grab_nth_branch_switch_cbdata cb;
+
+ if (name[0] != '@' || name[1] != '{' || name[2] != '-')
+ return -1;
+ for (i = 3, nth = 0; name[i] && name[i] != '}'; i++) {
+ char ch = name[i];
+ if ('0' <= ch && ch <= '9')
+ nth = nth * 10 + ch - '0';
+ else
+ return -1;
+ }
+ if (nth < 0 || 10 <= nth)
+ return -1;
+
+ cb.counting = 1;
+ cb.nth = 0;
+ cb.buf = buf;
+ for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+
+ cb.counting = 0;
+ cb.nth -= nth;
+ cb.buf = buf;
+ for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ return 0;
+}
+
/*
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
* notably "xyz^" for "parent of xyz"
^ permalink raw reply related
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Junio C Hamano @ 2009-01-15 20:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0901151517190.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 15 Jan 2009, Johannes Schindelin wrote:
>
>> [PATCH] pack-objects --all: include HEAD, which could be detached
>
> In hind sight, it would probably be better to add this to revision.c.
If you mean that "git log --all" should also include a possibly detached
HEAD in its traversal, and a patch that implements such a fix would
automatically fix "repack -a" without the patch you are responding to, I
think I agree 100%.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Jay Soffian @ 2009-01-15 20:26 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johan Herland, git, Johannes Schindelin, Junio C Hamano,
Sverre Rabbelier, Johannes Sixt, Anders Melchiorsen
In-Reply-To: <8035E52E-D202-4C42-BDFD-DC7A925580A3@wincent.com>
On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com> wrote:
> wait - best suggestion so far, seeing as we can't use "stop"
This is a fun game. I like the color "halt".
j.
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Johannes Sixt, git
In-Reply-To: <7vhc40s50t.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> >
> >> [PATCH] pack-objects --all: include HEAD, which could be detached
> >
> > In hind sight, it would probably be better to add this to revision.c.
>
> If you mean that "git log --all" should also include a possibly detached
> HEAD in its traversal, and a patch that implements such a fix would
> automatically fix "repack -a" without the patch you are responding to, I
> think I agree 100%.
Yes, indeed.
Something like
-- snip --
diff --git a/revision.c b/revision.c
index db60f06..b065184 100644
--- a/revision.c
+++ b/revision.c
@@ -1263,6 +1263,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (!strcmp(arg, "--all")) {
handle_refs(revs, flags, for_each_ref);
+ handle_refs(revs, flags, head_ref);
continue;
}
if (!strcmp(arg, "--branches")) {
-- snap --
but that was just a quick guess, and if nobody beats me to it, I'll turn
it into a proper patch later.
Ciao,
Dscho
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Junio C Hamano @ 2009-01-15 20:39 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: git
In-Reply-To: <20090115194926.GA6899@roro3.zxlink>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> Sorry for the inconvenience, and please pull them all from
>
> git://repo.or.cz/git/kirr.git for-junio
>
> Kirill Smelkov (4):
> mailinfo: 'From:' header should be unfold as well
> mailinfo: more smarter removal of rfc822 comments from 'From'
> mailinfo: correctly handle multiline 'Subject:' header
> mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Sorry, but I cannot _pull_ this one; not because these four patches are
bad (I haven't looked at them).
They include all the other totally unrelated stuff that happend on the
master branch since the topic ks/maint-mailinfo-folded forked. I've been
hoping upon completion of this topic we can merge it down to maint to
propagate the fix back to v1.6.1.X series.
With this alias:
$ git config alias.lg log --pretty=oneline --abbrev-commit --boundary --left-right
Here are what I have queued so far (and they are in next):
$ git lg master..ks/maint-mailinfo-folded
>ddfb369... mailinfo: 'From:' header should be unfold as well
>353aaf2... mailinfo: correctly handle multiline 'Subject:' header
-141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
$ git lg maint..ks/maint-mailinfo-folded
>ddfb369... mailinfo: 'From:' header should be unfold as well
>353aaf2... mailinfo: correctly handle multiline 'Subject:' header
-141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
141201d is only three commits ahead of v1.6.0.6 and
$ git lg v1.6.0.6..141201d
will show that we _could_ even issue v1.6.0.7 with the fixes in this topic
if we cared about this bug deeply enough. If I pull the above to the
topic, we'll lose the ability to propagate these fixes to the maintenance
serires.
So please either say "Yes, you are welcome to cherry-pick -- fetching and
cherry-picking would be easier than e-mail for this kind of patch", or
"Ok, I'll rebase my series on top of ddfb369".
Well, I just noticed that some of your commits already conflict with the
two patches that I already have, so I guess we would need at least one
rebase anyway, so this time around, I'd really prefer you not to say "you
are welcome to cherry-pick" ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Junio C Hamano @ 2009-01-15 20:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <7vocy8s51o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> So I think it is just the matter of coming up with a clever syntax that
> works on reflogs to name the nth last branch we were on and teach that
> syntax to both get_sha1() and resolve_ref().
>
> With the attached illustration patch,
>
> $ git checkout junk
> $ git chekcout master
> $ git checkout @{-1}
>
> will take you back to junk branch. It probably would serve as a starting
> point, if anybody is interested.
>
> NOTE!
> ...
> * interpret_nth_last_branch() is not hooked to get_sha1() codepath in
> this patch, so this is still only applicable to "git checkout". But it
> should be trivial to do so.
> ...
> +/*
> + * This reads "@{-N}" syntax, finds the name of the Nth previous
> + * branch we were on, and places the name of the branch in the given
> + * buf and returns 0 if successful.
> + *
> + * If the input is not of the accepted format, it returns a negative
> + * number to signal an error.
> + */
> +int interpret_nth_last_branch(const char *name, struct strbuf *buf)
A few more things to note.
* interpret_nth_last_branch() probably should return how many bytes it
consumed, instead of returning 0 in the successful case. This is to
allow things like "git merge @{-1}~2" to be easily parsed, either by
"git merge" itself into "git merge junk~2", which would result in
"Merge branch junk (early part)", or by get_sha1() which would result
in "Merge commit deadbeefacebeads".
* I mentioned resolve_ref() may need to be told about this syntax but I
do not think it is necessary. If a command that can take an arbitrary
refname or committish in the most general case does something special
when the end user input is a branch name ("git checkout" is a prime
example for this, but "git merge" also has this property, illustrated
by the previous "Merge branch junk" example), these commands has to do
their own special case logic before the user input hits get_sha1() or
resolve_ref() anyway (setup_branch_path() in builtin-checkout.c is a
good example of this), and such special case logic can and probably
should use interpret_nth_last_branch() directly.
^ permalink raw reply
* Re: [PATCH noindent 3/3] bash-completion: Added comments to remind about required arguments
From: Junio C Hamano @ 2009-01-15 21:01 UTC (permalink / raw)
To: ted; +Cc: spearce, git
In-Reply-To: <1232035343-10544-3-git-send-email-ted@tedpavlic.com>
Thanks, both. Applied.
^ permalink raw reply
* Re: [JGIT PATCH 8/8] Define a basic merge API, and a two-way tree merge strategy
From: Robin Rosenberg @ 2009-01-15 21:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <200810232314.29867.robin.rosenberg@dewire.com>
I never got a received reply... on this.
-- robin
torsdag 23 oktober 2008 23:14:29 skrev Robin Rosenberg:
> Hi, Shawn
>
> Shouldn't testTrivialTwoWay_disjointhistories() work?
>
> The two trees have nothing in common and so should be trivially mergeable.
>
> -- robin
>
> From cef2695431e368da616a1e9c8de3e5e419854a4c Mon Sep 17 00:00:00 2001
> From: Robin Rosenberg <robin.rosenberg@dewire.com>
> Date: Thu, 23 Oct 2008 23:09:10 +0200
> Subject: [EGIT PATCH] Simple merge test
>
> ---
> .../org/spearce/jgit/merge/SimpleMergeTest.java | 28 ++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
> create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
>
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
> new file mode 100644
> index 0000000..8ec1c7f
> --- /dev/null
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
> @@ -0,0 +1,28 @@
> +package org.spearce.jgit.merge;
> +
> +import java.io.IOException;
> +
> +import org.spearce.jgit.lib.ObjectId;
> +import org.spearce.jgit.lib.RepositoryTestCase;
> +
> +public class SimpleMergeTest extends RepositoryTestCase {
> +
> + public void testTrivialTwoWay_noway() throws IOException {
> + Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
> + boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
> + assertFalse(merge);
> + }
> +
> + public void testTrivialTwoWay_disjointhistories() throws IOException {
> + Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
> + boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c~4") });
> + assertTrue(merge);
> + }
> +
> + public void testTrivialTwoWay_ok() throws IOException {
> + Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
> + boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a^0^0^0"), db.resolve("a^0^0^1") });
> + assertTrue(merge);
> + assertEquals(db.mapTree("a^0^0").getId(), ourMerger.getResultTreeId());
> + }
> +}
^ permalink raw reply
* Re: cygwin git diff crash
From: Jeremy Ramer @ 2009-01-15 21:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901151631280.3586@pacific.mpi-cbg.de>
On Thu, Jan 15, 2009 at 8:34 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 15 Jan 2009, Jeremy Ramer wrote:
>
>> On Wed, Jan 14, 2009 at 3:33 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Wed, 14 Jan 2009, Jeremy Ramer wrote:
>> >
>> >> Ok this is a weird issue and it's probably cygwin's fault, but I
>> >> haven't found any way to fix it so I' thought I would throw it out
>> >> here for comment.
>> >>
>> >> I am using git 1.6.0.4 on cygwin. I have a repo where if any file has
>> >> changes and git detects as mode 100644 I get this error:
>> >> $git diff
>> >> 3 [main] git 2744 C:\cygwin\bin\git.exe: *** fatal error - could
>> >> not load user32, Win32 error
>> >>
>> >> If I change the mode to 100755 git diff will work fine.
>> >> $chmod a+x test.cpp
>> >> $git diff
>> >> diff --git a/test.cpp b/test.cpp
>> >> old mode 100644
>> >> new mode 100755
>> >> index 7c0dfcd..20987a7
>> >> --- a/test.cpp
>> >> +++ b/test.cpp
>> >> @@ -6,9 +6,11 @@ int main()
>> >>
>> >> void func()
>> >> {
>> >> + int a;^M
>> >> }
>> >>
>> >> void func2()
>> >> {
>> >> + int b;^M
>> >> }
>> >>
>> >> Anybody have a clue as to why this might occur? I have seen this in
>> >> many of the repo's I use, but it is not repeatable. I tried making a
>> >> test repo but could not reproduce.
>> >
>> > Wow, that _is_ weird. Does your test suite pass?
>> >
>> > Ciao,
>> > Dscho
>> >
>>
>> Forgive my ignorance, but I am not sure how to run the test suite. I
>> did a quick google search but didn't find anything. I am using
>> cygwin's packaged version of git and am not building it from source,
>> so maybe the suite is not available. If I get a chance I will try
>> building from source.
>
> It is really easy: just make sure that make, gcc, libiconv-dev,
> openssl-dev and libcurl-dev are installed (that's it AFAIR), then download
> a tarball, e.g.
>
> http://repo.or.cz/w/git.git?a=snapshot;h=next;sf=tgz
>
> unpack it, cd to it and run "make". (I would _not_ run configure...)
>
> Hth,
> Dscho
>
Well, after compiling from source the error seems to have disappeared.
Strange. I have seen it disappear before and come back later so I will
watch out for it, but for now it's not an issue.
Just a note, the cygwin names for the packages necessary to compile are
curl-devel
gcc
libiconv
make
openssl-devel
Jeremy
^ permalink raw reply
* Re: [JGIT PATCH 8/8] Define a basic merge API, and a two-way tree merge strategy
From: Shawn O. Pearce @ 2009-01-15 21:09 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200901152205.00600.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> I never got a received reply... on this.
Sorry. Its in my "pending" queue. I'm still using the code
in Gerrit but I've been so swamped that I haven't been able to
look at your test case, or what's wrong with the code and why it
doesn't pass.
I honestly hoped to have something by this point, but I got behind
and I haven't quite had a chance to look at it.
> torsdag 23 oktober 2008 23:14:29 skrev Robin Rosenberg:
> > Hi, Shawn
> >
> > Shouldn't testTrivialTwoWay_disjointhistories() work?
> >
> > The two trees have nothing in common and so should be trivially mergeable.
> >
> > -- robin
> >
> > From cef2695431e368da616a1e9c8de3e5e419854a4c Mon Sep 17 00:00:00 2001
> > From: Robin Rosenberg <robin.rosenberg@dewire.com>
> > Date: Thu, 23 Oct 2008 23:09:10 +0200
> > Subject: [EGIT PATCH] Simple merge test
> >
> > ---
> > .../org/spearce/jgit/merge/SimpleMergeTest.java | 28 ++++++++++++++++++++
> > 1 files changed, 28 insertions(+), 0 deletions(-)
> > create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Wincent Colaiuta @ 2009-01-15 21:58 UTC (permalink / raw)
To: Jay Soffian
Cc: Johan Herland, git, Johannes Schindelin, Junio C Hamano,
Sverre Rabbelier, Johannes Sixt, Anders Melchiorsen
In-Reply-To: <76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com>
El 15/1/2009, a las 21:26, Jay Soffian escribió:
> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com>
> wrote:
>> wait - best suggestion so far, seeing as we can't use "stop"
>
> This is a fun game. I like the color "halt".
Ooh, yes. An even better color.
Wincent
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Junio C Hamano @ 2009-01-15 22:09 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <20090115153529.GA13961@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> I think we might want do differentiate editing a commit (modifying
> either the commit message or the patch or both) or splitting a commit.
>
> The first is served well with the current 'edit' rebase command IMHO.
> I don't really see the point of the additional 'git reset --soft
> HEAD^'.
>
> * If you want to edit the commit message only, then you are
> better off with 'git commit --amend', because it preserves the
> previous commit message. But with 'git reset --soft HEAD^' and
> 'git commit' the commit message is "lost"; you have to use 'git
> commit -c ORIG_HEAD' instead, which is not that straightforward
> (and we don't have completion support for it).
I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
bad idea (you could still say commit -c @{1}, though).
> For the second we could introduce a new rebase command like 'split',
> which would do the same as 'edit' but would also perform that 'git
> reset HEAD^' mentioned in the documentation automatically.
Perhaps.
^ permalink raw reply
* mistake in Release Notes for 1.6.2
From: Markus Heidelberg @ 2009-01-15 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hello Junio,
Documentation/RelNotes-1.6.2.txt:
> * git-cherry defaults to HEAD when the <upstream> argument is not given.
This is not correct, see commit f2968022 (2008-12-29):
git-cherry: make <upstream> parameter optional
The upstream branch <upstream> now defaults to the first tracked
remote branch, which is set by the configuration variables
branch.<name>.remote and branch.<name>.merge of the current branch.
Without such a remote branch, the command "git cherry [-v]" fails with
usage output as before and an additional message.
I guess it's a mistake in hurry, not every default value is HEAD :)
Markus
^ 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