* Re: [PATCH 2/2] api-run-command.txt: talk about run_hook()
From: Miklos Vajna @ 2009-01-15 16:12 UTC (permalink / raw)
To: Jakub Narebski
Cc: Stephan Beyer, git, Paolo Bonzini, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <m38wpczi09.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Thu, Jan 15, 2009 at 07:49:51AM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> > + The further variable number (up to 9) of arguments correspond
> > + to the hook arguments.
> > + The last argument has to be NULL to terminate the variable
> > + arguments list.
>
> Why the limitation of maximum of 9 hook arguments?
That's how it is in builtin-commit at the moment, and I agree with Dscho
about it could be a separate patch to remove this limitation.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 16:24 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de>
On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The intention was this:
>
> $ git rebase -p master
>
> would need to rewrite _all_ commits that are in "master..". All of them,
> including the merge commits.
I went hog wild with all sorts of test cases and my head is
spinning, but -- even when things happen more predictably,
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.
Regards,
Sitaram
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johan Herland @ 2009-01-15 16:32 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Johannes Sixt, Thomas Rast, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151413250.3586@pacific.mpi-cbg.de>
On Thursday 15 January 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Jan 2009, Johannes Sixt wrote:
> > Thomas Rast schrieb:
> > > 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.
> >
> > /me likes this feature.
> >
> > git rebase (-i or not) calls checkout behind the scenes if the
> > two-argument form is used:
> >
> > git rebase [-i] master topic
> >
> > and 'topic' is not the current branch. You may want to add a test
> > that ensures that rebase sets LAST_HEAD in this case.
> >
> > You must make sure that commits referenced by LAST_HEAD are not
> > garbage-collected. (I don't know if this happens anyway for symrefs
> > in .git.)
>
> Note: if you used reflogs for that feature, the garbage collection
> could not have killed the commit. However, it is quite possible that
> the branch was deleted.
I also like this feature, but as this is only a _convenience_ feature, I
would prefer if it didn't keep the previous branch/commit alive (if
otherwise unreachable). In any case, this new feature will _have_ to
handle the case where there simply is no previous branch/commit (e.g.
after a git clone or git init).
I suggest that "git checkout -" looks at the reflog, and if there is no
previous entry in the reflog, or that entry is unreachable, then fail
in the same manner as "git checkout garbage"
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 16:43 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Michael J Gruber, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <20090115144050.GD10045@leksak.fem-net>
Hi,
On Thu, 15 Jan 2009, Stephan Beyer wrote:
> Michael J Gruber wrote:
> > If it's about to be integrated we can do without the
> > present script...
>
> I think it will take some time and some discussions on the list until it
> will be integrated. I remember, for example, Dscho, who has, since it
> had first come up, always been opposed to the mark-reset /
> mark-reset-merge scheme (in rebase -i -p, at least). Other users said
> "Wow, this is much more flexible." ... and this is perhaps only one
> thing that can lead to some bigger discussion.
Wow, much more flexible. Except that you should not need this kind of
flexibility. If you need to do something complicated, it would be better
to use "rebase -i -p" for the parts that do _not_ need to pick _other_
parents than are recorded in the commits.
And then you do an "edit" (or "pause" or whatever), and cherry-pick/merge
_explicitely_ what you want.
Further, keep in mind that not only is that flexibility of dubitable value
to the most users, it is also confusing, _and_ it adds code that is so
rarely exercized that bugs can lurk in there for years... as you can
experience right now.
So no, nothing has changed, I find that mark idea still horrible,
horrible, horrible.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 16:50 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Sixt, Thomas Rast, Junio C Hamano
In-Reply-To: <200901151732.57023.johan@herland.net>
Hi,
On Thu, 15 Jan 2009, Johan Herland wrote:
> On Thursday 15 January 2009, Johannes Schindelin wrote:
>
> > On Thu, 15 Jan 2009, Johannes Sixt wrote:
> > > Thomas Rast schrieb:
> > > > 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.
> > >
> > > /me likes this feature.
> > >
> > > git rebase (-i or not) calls checkout behind the scenes if the
> > > two-argument form is used:
> > >
> > > git rebase [-i] master topic
> > >
> > > and 'topic' is not the current branch. You may want to add a test
> > > that ensures that rebase sets LAST_HEAD in this case.
> > >
> > > You must make sure that commits referenced by LAST_HEAD are not
> > > garbage-collected. (I don't know if this happens anyway for symrefs
> > > in .git.)
> >
> > Note: if you used reflogs for that feature, the garbage collection
> > could not have killed the commit. However, it is quite possible that
> > the branch was deleted.
>
> I also like this feature, but as this is only a _convenience_ feature, I
> would prefer if it didn't keep the previous branch/commit alive (if
> otherwise unreachable).
You misread me: if the information is in HEAD's reflog, the _is_
reachable. From HEAD's reflog. And therefore, the objects will not be
gc'ed (yet).
> In any case, this new feature will _have_ to handle the case where there
> simply is no previous branch/commit (e.g. after a git clone or git
> init).
>
> I suggest that "git checkout -" looks at the reflog, and if there is no
> previous entry in the reflog, or that entry is unreachable, then fail
> in the same manner as "git checkout garbage"
Exactly my thinking.
Ciao,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 16:53 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmuoq8.3u2.sitaramc@sitaramc.homelinux.net>
Hi,
if you would like me to respond to your questions in the future, it is
mandatory to keep me in the Cc: list.
On Thu, 15 Jan 2009, Sitaram Chamarty wrote:
> On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > The intention was this:
> >
> > $ git rebase -p master
> >
> > would need to rewrite _all_ commits that are in "master..". All of them,
> > including the merge commits.
>
> I went hog wild with all sorts of test cases and my head is
> spinning, but -- even when things happen more predictably,
> 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.
Hth,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 16:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de>
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.
Michael
^ 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 16:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <bd6139dc0901150445l51f3b861n5bbd85bb6d1382b6@mail.gmail.com>
"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 ;-).
^ permalink raw reply
* [JGIT PATCH] Fix RawParseUtils to match on the end of the buffer
From: Shawn O. Pearce @ 2009-01-15 17:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
When we were matching exactly on the end of the buffer the match
method was failing because it incorrectly tested for >= on the
buffer length. We only needed to test for > the buffer length.
JUnit tests for the match function are included to test for this
condition, and others.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/util/RawParseUtils_MatchTest.java | 69 ++++++++++++++++++++
.../src/org/spearce/jgit/util/RawParseUtils.java | 4 +-
2 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_MatchTest.java
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_MatchTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_MatchTest.java
new file mode 100644
index 0000000..32270b7
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_MatchTest.java
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.util;
+
+import junit.framework.TestCase;
+
+import org.spearce.jgit.lib.Constants;
+
+public class RawParseUtils_MatchTest extends TestCase {
+ public void testMatch_Equal() {
+ final byte[] src = Constants.encodeASCII(" differ\n");
+ final byte[] dst = Constants.encodeASCII("foo differ\n");
+ assertTrue(RawParseUtils.match(dst, 3, src) == 3 + src.length);
+ }
+
+ public void testMatch_NotEqual() {
+ final byte[] src = Constants.encodeASCII(" differ\n");
+ final byte[] dst = Constants.encodeASCII("a differ\n");
+ assertTrue(RawParseUtils.match(dst, 2, src) < 0);
+ }
+
+ public void testMatch_Prefix() {
+ final byte[] src = Constants.encodeASCII("author ");
+ final byte[] dst = Constants.encodeASCII("author A. U. Thor");
+ assertTrue(RawParseUtils.match(dst, 0, src) == src.length);
+ assertTrue(RawParseUtils.match(dst, 1, src) < 0);
+ }
+
+ public void testMatch_TooSmall() {
+ final byte[] src = Constants.encodeASCII("author ");
+ final byte[] dst = Constants.encodeASCII("author autho");
+ assertTrue(RawParseUtils.match(dst, src.length + 1, src) < 0);
+ }
+}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index a6a50bb..758e7af 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -71,10 +71,10 @@
* first position within b, this should match src[0].
* @param src
* the buffer to test for equality with b.
- * @return ptr += src.length if b[ptr..src.length] == src; else -1.
+ * @return ptr + src.length if b[ptr..src.length] == src; else -1.
*/
public static final int match(final byte[] b, int ptr, final byte[] src) {
- if (ptr + src.length >= b.length)
+ if (ptr + src.length > b.length)
return -1;
for (int i = 0; i < src.length; i++, ptr++)
if (b[ptr] != src[i])
--
1.6.1.233.g5b4a8
^ permalink raw reply related
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-15 17:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151510340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
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.
> - 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.
> - 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?
> - 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. I wanted to be able to abbreviate the previous branch's name,
and it does just that.
> - 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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 17:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <7vmydsv72u.fsf@gitster.siamese.dyndns.org>
On Thu, Jan 15, 2009 at 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> 'stop' would be closest to what it currently does. It stops and it is up
> to you how to screw up the result ;-).
Hmmm, yes, I think that would be a better alias; but I think I like
the idea to wait for changes like this till sequencer goes in, mhh?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Andreas Bombe @ 2009-01-15 16:54 UTC (permalink / raw)
To: Kyle Moffett
Cc: Christian Borntraeger, Linus Torvalds, Sam Ravnborg,
Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <f73f7ab80901131226s6af7730cucf9c44bc2b4f9545@mail.gmail.com>
On Tue, Jan 13, 2009 at 03:26:09PM -0500, Kyle Moffett wrote:
> On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
> > In my opinion we should really avoid subtree merges in the future as a curtesy
> > to people who do the uncool work of testing, problem tracking and bisecting.
> > </rant>
>
> As an alternative, you can relatively easily rewrite the following
> independent histories:
>
> A -- B -- C
> X -- Y -- Z
>
> To look like this:
>
> A -- B -- C -- X' -- Y' -- Z'
>
> Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...
Given that the subtree may have been in development for a long time, it
is almost a certainty that the older commits may compile on A but not
on C. By basing it all on C you create a lot of uncompilable commits
which hurt bisection just as bad. At least with missing kernel sources
it is obvious that an attempt at compilation is futile and a waste of
time.
^ permalink raw reply
* 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
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