* Re: [PATCH take 3 0/4] color-words improvements
From: Santi Béjar @ 2009-01-16 0:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Teemu Likonen, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901151940170.3586@pacific.mpi-cbg.de>
2009/1/15 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>> I didn't see the semantics of color-words documented in the original
>> either,
>
[...]
>> 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.
It may be ok and logical, but for me it is not what I want. Mmaybe I
don't really undestand what I want or is a crazy idea but here it is
anyway:
Take a simple case with this two lines :
matrix[a,b,c]
matrix{d,b,c}
there is no space so the standard color-words does not help to
visualize that matrix, the b and c are not changed.
What I currently do is to add some spaces:
matrix[ a, b, c ]
matrix{ d, b, c }
then the color-words at least says that "b, c" is unchanged.
What I would like is that --color-words would act as adding this
spaces automatically (and even one after "matrix").
Or another way to think it could be:
a) primary words are those with alphanumerics (or a regex)
b) secondary "words" are the other non-whitespaces characters (in this
case "[]{} and ,"
c) whitespaces are cruft.
(having two regexp to specify what is a words but they cannot mix).
If everything works as I think (it's late night :-) with the above two lines:
matrix[a,b,c]
matrix{d,b,c}
the word diff would be
matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
Santi
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Kyle Moffett @ 2009-01-15 23:13 UTC (permalink / raw)
To: Kyle Moffett, Christian Borntraeger, Linus Torvalds, Sam Ravnborg,
"Johanne
In-Reply-To: <20090115165425.GA7517@bombe-desk.opditex>
On Thu, Jan 15, 2009 at 11:54 AM, Andreas Bombe <andreas.bombe@mytum.de> wrote:
> 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.
No, the older commits will compile just fine as they don't actually
reference the new code from any of the parent makefiles. It would
effectively be "dead code" until the "merge" in the commit *after* Z'
in which you add lines to "sub/Kconfig" and "sub/Kbuild" which
reference "sub/dir/*".
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Markus Heidelberg @ 2009-01-15 23:09 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com>
skillzero@gmail.com, 14.01.2009:
> On Wed, Jan 14, 2009 at 12:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
> > After you created the fixup, you have this situation:
> >
> > o--o--o <- A (feature branch)
> > /
> > --o--x <- X (the fix-up branch)
> > \
> > o--o--o <- Z (probably your master)
> >
> > You merge the fix-up into the feature branch and continue developing the
> > feature:
> >
> > o--o--o--M--o--o <- A
> > / /
> > --o--x-----' <- X
> > \
> > o--o--o <- Z
> >
> > Other people need the fix in Z right now, so you merge it into Z as well:
> >
> > o--o--o--M--o--o <- A
> > / /
> > --o--x-----< <- X
> > \ \
> > o--o--o--N <- Z
> >
> > You complete your feature and merge it into Z:
> >
> > o--o--o--M--o--o <- A
> > / / \
> > --o--x-----< \ <- X
> > \ \ \
> > o--o--o--N---------O <- Z
> >
> > The fix-up commit is only once in your history.
>
> Thanks for the info. That's what I was hoping, but I was thinking that
> I'd get duplicate commits if I did that. I'll have to try it out when
> I run into this situation again.
Note, that you'd get 2 merge commits for this fix-up commit into branch Z.
The first from merging X into Z, the second is created from merging X
into A and occures in Z when merging A into it.
Markus
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Markus Heidelberg @ 2009-01-15 23:04 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090115222905.8157.qmail@science.horizon.com>
George Spelvin, 15.01.2009:
> While you're at it, an option to search the entire git tree rather than
> the current subdirectory would also be useful. I was thinking about
> a flag like -r (for "root"), but a second idea dawned on me: interpret
> absolute pathnames as relative to the root of the repository. So I could
> "git grep <pattern> /" or "git grep <pattern> /include" from any subdirectory.
I have never used submodules execpt for trying out, but I think it would
ambigous when calling this command from inside a submodule. It's not
clear, whether the main repo or the submodule should be used.
Markus
^ permalink raw reply
* Re: [PATCH 1/2] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Junio C Hamano @ 2009-01-15 22:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, git, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <alpine.DEB.1.00.0901151637590.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 15 Jan 2009, Stephan Beyer wrote:
>
>> Stripping out a libified version seemed better to me than
>> copy and paste.
>
> Oh, definitely.
>
>> - ret = start_command(&hook);
>> - if (ret) {
>> - warning("Could not spawn %s", argv[0]);
>> - return ret;
>> - }
>> - ret = finish_command(&hook);
>> - if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
>> - warning("%s exited due to uncaught signal", argv[0]);
>
> What are the side effects of replacing this with "ret =
> run_command(&hook);"? This has to be discussed and defended in the commit
> message.
I think the answer is "Lost warnings here and there".
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: SZEDER Gábor @ 2009-01-15 22:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, SZEDER Gábor, Anders Melchiorsen, git,
Johannes.Schindelin
In-Reply-To: <bd6139dc0901151420j4ae62433uc0cc70d86dc45cfa@mail.gmail.com>
On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:
> On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> > I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> > bad idea (you could still say commit -c @{1}, though).
>
> But it's not:
> "It also makes sure that a pre-filled editor is fired up when doing
> "git rebase --continue", in case the user just wanted to fix the
> commit message."
Indeed, but in this case the rebase process will continue after
finishing the commit message. OTOH, with the current behaviour, you
must do a 'git commit --amend && git rebase --continue', which might
seem more complicated at first sight, but...
But the current behaviour of the 'edit' rebase command gives you the
possibility of adding further commits on top of the selected one
(after you have edited that or left intact, doesn't matter). To do
that with this automatic 'reset --soft HEAD^' modification you would
first need to 'git commit -c @{1}' to keep the selected commit before
going on with adding further commits, which is not quite nice.
Regards,
Gábor
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Markus Heidelberg @ 2009-01-15 22:56 UTC (permalink / raw)
To: Adeodato Simó
Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <20090113201024.GA20129@chistera.yi.org>
Adeodato Simó, 13.01.2009:
> * Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
>
> > On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
> > >See [...] how the subject is a niceshort, one
> > >line summary of the module impacted and the change?
>
> > My rule for this is absolutely no more than 80 characters.
>
> My rule for *all* of the commit message is "absolutely no more than 76
> characters". With more than 76, `git log` wraps in a 80-column terminal.
What about the 50 character limit proposed in the documentation
(git-commit, gittutorial, user-manual)?
At the beginning I tried to fulfil this limit, but often it's not easy.
So should it be adjusted to a slightly higher value in the documentation
or even split into a recommended limit (e.g. 50) and a recommended
absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
Markus
^ permalink raw reply
* fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-15 22:29 UTC (permalink / raw)
To: git
Could someone fix this some day? "git grep <pattern> ../include"
is something I find myself wanting quite frequently, and it's a fresh
annoyance every time I type it to discover that it still doesn't work.
While you're at it, an option to search the entire git tree rather than
the current subdirectory would also be useful. I was thinking about
a flag like -r (for "root"), but a second idea dawned on me: interpret
absolute pathnames as relative to the root of the repository. So I could
"git grep <pattern> /" or "git grep <pattern> /include" from any subdirectory.
As it is currently, absolute pathnames don't work very well either...
[1]$ git grep xyzzy $PWD
fatal: '/home/linux/project/src' is outside repository
[2]$ cd /usr/src/linux
[3]$ git grep xyzzy $PWD
CREDITS:E: rjd@xyzzy.clara.co.uk
drivers/hwmon/hwmon-vid.c: * With assistance from Trent Piepho <xyzzy@speakeasy.
drivers/infiniband/hw/ipath/ipath_debug.h: * if(infinipath_debug & _IPATH_xyzzy)
drivers/media/dvb/frontends/or51132.c: * Copyright (C) 2007 Trent Piepho <xyz
drivers/media/video/cx88/cx88-alsa.c: * (c) 2007 Trent Piepho <xyzzy@speakeas
drivers/video/intelfb/intelfbhw.c: /* do some funky magic - xyzzy */
include/linux/byteorder/swab.h: * Trent Piepho <xyzzy@speakeasy.org> 2007114
include/linux/hwmon-vid.h: With assistance from Trent Piepho <xyzzy@speakeasy
[4]$ cd include
[5]$ git grep xyzzy $PWD
fatal: git grep: cannot generate relative filenames containing '..'
I don't quite understand that last error message.
Thank you.
^ permalink raw reply
* Re: git-difftool
From: Markus Heidelberg @ 2009-01-15 22:26 UTC (permalink / raw)
To: David Aguilar; +Cc: Matthieu Moy, git
In-Reply-To: <402731c90901020939k1a8ae795oc4cbfd0ced992aab@mail.gmail.com>
David Aguilar, 02.01.2009:
> I now have a git-difftool wrapper script that basically just sets up
> the environment for git-difftool-helper. git-difftool-helper does all
> of the merge tool configuration stuff ala
> http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html (it
> uses the same git config variables and thus works with existing custom
> commands). If you drop them both into the same directory it should
> work as-is (it munges $PATH).
>
> It's not a two-liner (they do all that git config stuff and handle
> more than just vimdiff) but it does use GIT_EXTERNAL_DIFF now, which
> makes the script infinitely more useful. This is much nicer now since
> you can pass any 'git diff' options to git-difftool and it'll handle
> it correctly.
>
> The usage is simpler now too:
>
> usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
Now isn't this something for contrib, David?
Markus
^ permalink raw reply
* Re: [StGit PATCH] Check for local changes with "goto"
From: Catalin Marinas @ 2009-01-15 22:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090115083700.GB24890@diana.vm.bytemark.co.uk>
2009/1/15 Karl Hasselström <kha@treskal.com>:
> I'm not opposed to the change as such (even if I personally think it's
> very convenient to allow operations like goto if the local changes
> don't touch the same files), but ...
That would work if "refresh" only commits files previously added to
the patch (the same way as quilt). I found myself many times moving to
another patch and refreshing more than I wanted to add to that patch
because I forgot to run "status" before "goto".
Maybe we can make this configurable to accommodate both variants
(would be even easier if I move the check to transaction.py).
> On 2009-01-14 22:59:45 +0000, Catalin Marinas wrote:
>
>> stgit/commands/common.py | 7 +++++++
>> stgit/commands/goto.py | 8 +++++++-
>
> ... are you sure it wouldn't be better to build the check into
> transaction.py, so that all new-infrastructure command would share it?
OK, I'll do this and repost.
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 22:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <7vvdsgql17.fsf@gitster.siamese.dyndns.org>
On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> bad idea (you could still say commit -c @{1}, though).
But it's not:
"It also makes sure that a pre-filled editor is fired up when doing
"git rebase --continue", in case the user just wanted to fix the
commit message."
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Junio C Hamano @ 2009-01-15 22:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <496F15B4.2040104@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I'm happy to follow any variant ("1+2+3", "1 2+3", "1 2 3", in
> increasing order of preference) so there's no need to discuss or explain
> this further, just tell me "do x" ;)
Do nothing ;-) Your 1=3772923 and 2+3=be17262d are already in and we can
include the fix in the next 1.6.1.X maintenance release.
Thanks.
^ 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
* 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
* 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: [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: 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: 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: [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: [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: 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: 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: [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: 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: [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