* Re: UI and git-completion.sh
From: Brian Downing @ 2007-10-24 0:57 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <20071024005549.GC24924@lavos.net>
On Tue, Oct 23, 2007 at 07:55:49PM -0500, Brian Downing wrote:
> I dunno the "right" way to do it, but I had this in my .zshrc file that
> I presumably cargo-culted from somewhere:
>
> fpath=( $HOME/.zsh/compfuncs $fpath )
I think this has to come before "compinit" or whatever starts up the new
completion engine.
-bcd
^ permalink raw reply
* Re: UI and git-completion.sh
From: Brian Downing @ 2007-10-24 0:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <86d4v59wvt.fsf@blue.stonehenge.com>
On Tue, Oct 23, 2007 at 05:31:02PM -0700, Randal L. Schwartz wrote:
> Yes, so what is the process of adding the git zsh completion to any
> relatively stable version of zsh? Someone here must know.
I dunno the "right" way to do it, but I had this in my .zshrc file that
I presumably cargo-culted from somewhere:
fpath=( $HOME/.zsh/compfuncs $fpath )
So in addition to that, doing:
wget -O ~/.zsh/compfuncs/_git 'http://zsh.cvs.sourceforge.net/*checkout*/zsh/zsh/Completion/Unix/Command/_git'
might get you something. I guess if your zsh is too old it might be
incompatible with the completion script, though...
-bcd
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <vpqbqapgx0j.fsf@bauges.imag.fr>
>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Matthieu> http://zsh.cvs.sourceforge.net/zsh/zsh/Completion/Unix/Command/_git
Matthieu> Try adding it to your $fpath, hopefully, the new _git doesn't use the
Matthieu> other new zsh features, and it will work (I have a CVS _git with a
Matthieu> 4.3.4 zsh, and it works like a charm).
Do I add it as _git below my $fpath? Or do I need to put it into a subdir?
How will it know it is there?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: UI and git-completion.sh
From: Matthieu Moy @ 2007-10-24 0:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <86prz59y9s.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
> Matthieu> In zsh itself.
>
> Matthieu> Completion/Unix/Command/_git
>
> Not in my version of zsh. Any chance I can add that to my 4.2.3
> installation?
http://zsh.cvs.sourceforge.net/zsh/zsh/Completion/Unix/Command/_git
Try adding it to your $fpath, hopefully, the new _git doesn't use the
other new zsh features, and it will work (I have a CVS _git with a
4.3.4 zsh, and it works like a charm).
--
Matthieu
^ permalink raw reply
* Re: [PATCH 0/9] Make git-svn fetch ~1.7x faster
From: Sam Vilain @ 2007-10-24 0:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, aroben
In-Reply-To: <20071023060812.GA30978@glandium.org>
Mike Hommey wrote:
> On Mon, Oct 22, 2007 at 10:46:28PM -0700, Adam Roben wrote:
>> This patch series makes git-svn fetch about 1.7x faster by reducing the number
>> of forks/execs that occur for each file retrieved from Subversion. To do so, a
>> few new options are added to git-cat-file and git-hash-object to allow
>> continuous input on stdin and continuous output on stdout, so that one instance
>> of each of these commands can be kept running for the duration of the fetch.
>
> You don't need to do this to avoid forks. Just use git-fast-import
> instead.
git-fast-import only covers the hash-object side of things, not cat-file.
git-fast-import does not currently suit 'gradual deployment' for
converters such as git-svn, because it;
- returns object IDs at the end, when you checkpoint.
This could be 'fixed' by allowing a marks log file instead of or in
addition to the current behaviour, though if the exporter is
continually waiting for the tokens rather than using marks, it will
slow it down.
- you can't use plumbing commands, such as rev-parse, cat-file, etc on
objects which have not been checkpointed yet.
- can't just stream a file of unknown length to it as you can to
hash-object
These are the design trade-offs of using fast-import. Using
fast-import, you are creating a 'transaction' area which uses user
sequences instead of (git)database-issued identifiers. And this
transaction is isolated from the other concurrent users of the object
database. However the interface does not have the full git CLI
available to it, so unlike a regular database transaction, you end up
having to care.
Rewriting the importer so as to correctly deal with these problems is
quite challenging, and for slow import sources such as Subversion, of
limited merit.
Sam.
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:31 UTC (permalink / raw)
To: Steven Grimm; +Cc: Matthieu Moy, Paolo Ciarrocchi, git
In-Reply-To: <471E91C9.3000004@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> And I think we've just proven that more documentation is required
Steven> here! (I have no idea how to enable it myself; I just know I've seen
Steven> it mentioned on the list from time to time.)
Yes, so what is the process of adding the git zsh completion to any relatively
stable version of zsh? Someone here must know.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Salikh Zakirov @ 2007-10-24 0:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021020653.GA14735@spearce.org>
Shawn O. Pearce wrote:
> Hmm. Lets see.
>
> "cvs foo":
> Big spew of commands. Like "git foo".
>
> "svn foo":
> Unknown command: 'foo'
> Type 'svn help' for usage.
>
> Both are considered to be more newbie friendly then Git. So clearly
> SVN's output of almost nothing is friendly. And so is CVS'
> big spew of frequently used commands. Either way is apparently
> newbie friendly.
>
> Though I find SVN's message a little insulting, asking me to type.
> I know I have to type the command, thanks.
On the contrary, I consider CVS and current Git output more insulting,
as it assumes I forgot all the commands every time I made a typo.
The polite part of the message is to point out a typo,
as "Unknown command 'foo'" above. The "Type "svn help" for usage" part
is just a reminder for complete newbies, which doesn't take too much space
and can be reasonably ignored by experienced users.
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-24 0:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710231647350.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> Happened for just a random directory I tested. According to my bash
> history, it seems to have been
>
> gitk v2.6.23.. drivers/char/
Ahhhh... It's the slash on the end that does it (it works properly
without the slash). I just pushed out a fix for that (and a couple of
other bugs I just found).
Paul.
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-24 0:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <vpqir4xgzep.fsf@bauges.imag.fr>
>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Matthieu> In zsh itself.
Matthieu> Completion/Unix/Command/_git
Not in my version of zsh. Any chance I can add that to my 4.2.3 installation?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: UI and git-completion.sh
From: Matthieu Moy @ 2007-10-23 23:54 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Grimm, Paolo Ciarrocchi, git
In-Reply-To: <86ve8x9z1f.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
>
> Steven> Also might be worth mentioning the zsh completion support. (I know it's there,
> Steven> but haven't used it -- maybe its author would care to describe it a bit?)
>
> Where is it? I'm a zsh user, and would love to have git support.
In zsh itself.
Completion/Unix/Command/_git
--
Matthieu
^ permalink raw reply
* Re: gitk patch collection pull request
From: Linus Torvalds @ 2007-10-23 23:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18206.34254.741787.255299@cargo.ozlabs.ibm.com>
On Wed, 24 Oct 2007, Paul Mackerras wrote:
>
> Is it completely empty, or does it have just the "Comments" entry at
> the top?
Just the comment.
> Can you give me an example of a gitk command line that shows the
> problem on the kernel tree?
Happened for just a random directory I tested. According to my bash
history, it seems to have been
gitk v2.6.23.. drivers/char/
which is pretty basic..
Linus
^ permalink raw reply
* Re: UI and git-completion.sh
From: Randal L. Schwartz @ 2007-10-23 23:44 UTC (permalink / raw)
To: Steven Grimm; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <471E6EF0.2060403@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> Also might be worth mentioning the zsh completion support. (I know it's there,
Steven> but haven't used it -- maybe its author would care to describe it a bit?)
Where is it? I'm a zsh user, and would love to have git support.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-23 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710231214150.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> Ok, the diff looks fine, but now the "list of files" pane on the right is
> empty.
Really? It looks OK here - that is, it lists the names of the files
whose diffs are shown on the left, i.e. the files modified by the
commit that are within the path limit.
Is it completely empty, or does it have just the "Comments" entry at
the top?
Can you give me an example of a gitk command line that shows the
problem on the kernel tree?
Paul.
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-23 22:45 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, msysGit
In-Reply-To: <5AD0C329-7136-42A3-9202-865E70A29B65@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 21, 2007, at 8:47 AM, Steffen Prohaska wrote:
>
> >How can I switch msysgit's git-gui to English, independently of
> >the language selected for Windows? I recognized that git-gui
> >adjusts to the 'language selection' of Windows. How can I
> >disable this? I want git-gui to always display English. Nothing
> >else, never! I can't help people who use a different language
> >in the gui, because I'll not understand what they are talking
> >about and they'll not understand me.
>
> And it's even worse. An error in the localization can completely
> break git-gui. Apparently the German localization included in
> msysgit's Git-1.5.3-preview20071019.exe _is_ broken (see
> attached png).
>
> Shouldn't the localization code be a bit more fault tolerant?
Yes. This is a possible workaround:
>From 410aa617e7ca8240500e90f0b0389bde7b7b40aa Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Tue, 23 Oct 2007 18:44:55 -0400
Subject: [PATCH] git-gui: Protect against bad translation strings
If a translation string uses a format character we don't have an
argument for then it may throw an error when we attempt to format
the translation. In this case switch back to the default format
that comes with the program (aka the English translation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 38c6e59..a7227ac 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -88,13 +88,20 @@ if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
package require msgcat
-proc mc {fmt args} {
- set fmt [::msgcat::mc $fmt]
+proc _mc_trim {fmt} {
set cmk [string first @@ $fmt]
if {$cmk > 0} {
- set fmt [string range $fmt 0 [expr {$cmk - 1}]]
+ return [string range $fmt 0 [expr {$cmk - 1}]]
}
- return [eval [list format $fmt] $args]
+ return $fmt
+}
+
+proc mc {en_fmt args} {
+ set fmt [_mc_trim [::msgcat::mc $en_fmt]]
+ if {[catch {set msg [eval [list format $fmt] $args]} err]} {
+ set msg [eval [list format [_mc_trim $en_fmt]] $args]
+ }
+ return $msg
}
proc strcat {args} {
--
1.5.3.4.1324.ga7925
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
From: Andreas Ericsson @ 2007-10-23 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Johannes Schindelin, git
In-Reply-To: <7v640x7a4n.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sort of offtopic, but is "factorise" a correct verb here? I
> thought "factorise" is to express a non prime number as the
> product of prime numbers.
>
It's the reverse of expanding brackets, like so:
2x² + x - 3 = (2x + 3)(x - 1)
> "refactor" is the act of splitting and merging pieces of
> functions for better reuse, isn't it?
>
Yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
From: J. Bruce Fields @ 2007-10-23 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Johannes Schindelin, git
In-Reply-To: <7v640x7a4n.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 23, 2007 at 03:13:12PM -0700, Junio C Hamano wrote:
> Sort of offtopic, but is "factorise" a correct verb here? I
> thought "factorise" is to express a non prime number as the
> product of prime numbers.
"Factor" is a perfectly good verb on its own, no need for the "ise"
normally.
--b.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Alex Riesen @ 2007-10-23 22:13 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Andreas Ericsson, Jakub Narebski,
Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com>
Wincent Colaiuta, Mon, Oct 22, 2007 15:17:19 +0200:
>
>> So once again, what operations involving git do people use regularly?
>
> Here are my top ten commands, sorted by the number of times they appear in
> my ~/.bash_history:
from my (short, 500) .bash_history:
26 am
22 gitk
21 fetch
15 reset
10 log
9 merge
8 cherry-pick
7 status
5 commit
4 svn
4 push
4 gc
4 diff
3 gui
3 format-patch
2 pull
2 clone
1 show
1 rebase
1 grep
1 cat-file
1 branch
1 apply
branch, cat-file and show are actually fairly common, the history just
shorted and I lost them.
^ permalink raw reply
* Re: [PATCH 4/7] Bisect: factorise "bisect_write_*" functions.
From: Junio C Hamano @ 2007-10-23 22:13 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git
In-Reply-To: <20071014142938.d722299c.chriscool@tuxfamily.org>
Sort of offtopic, but is "factorise" a correct verb here? I
thought "factorise" is to express a non prime number as the
product of prime numbers.
"refactor" is the act of splitting and merging pieces of
functions for better reuse, isn't it?
^ permalink raw reply
* Re: UI and git-completion.sh
From: Steven Grimm @ 2007-10-23 22:00 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071023234617.45a4fc64@paolo-desktop>
Paolo Ciarrocchi wrote:
> What people think about starting suggesting the usage of the script in the documentation?
>
Also might be worth mentioning the zsh completion support. (I know it's
there, but haven't used it -- maybe its author would care to describe it
a bit?)
-Steve
^ permalink raw reply
* UI and git-completion.sh
From: Paolo Ciarrocchi @ 2007-10-23 21:46 UTC (permalink / raw)
To: git
Hi all,
I just asked for help on the #git irc channel in order to install
the .git-completion.sh script (thanks nessundorma) and after using it
for a while I started wondering why I cannot find any reference to it the
official documentation.
The only important think that git grep found is:
paolo@paolo-desktop:~/git$ git grep completion *
Documentation/RelNotes-1.5.0.txt: - Bash completion scripts have been updated heavily.
Shouldn't it be mentioned somewhere?
I know that newbies are somehow scared by the following:
paolo@paolo-desktop:~/git$ git-
Display all 151 possibilities? (y or n)
What? Do I have to learn 151 commands?
No way!
Using the git-completation script it all boils down to 48 commands.
paolo@paolo-desktop:~/git$ git
add fetch rebase
am filter-branch rebase--interactive
annotate format-patch relink
apply fsck remote
archive gc repack
bisect get-tar-commit-id request-pull
blame grep reset
branch gui resolve
bundle imap-send revert
checkout init rm
checkout-index instaweb send-email
cherry log shortlog
cherry-pick lost-found show
citool ls-files show-branch
clean ls-remote show-ref
clone ls-tree stash
commit merge status
config mergetool submodule
convert-objects mv tag
count-objects name-rev var
describe pickaxe verify-pack
diff pull whatchanged
diff-stages push
And I think I can remove some commands from the list.
What people think about starting suggesting the usage of the script in the documentation?
I just want to know the opinion of the list before trying to write a documentation patch.
Next step would be to reduce the number of the items listed by git <tab> but I know there is
already a discussion about it on the list.
Regards,
Paolo
^ permalink raw reply
* Re: [PATCH 1/2] rev-list: implement --bisect-all
From: Junio C Hamano @ 2007-10-23 21:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, git
In-Reply-To: <Pine.LNX.4.64.0710080607180.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 8 Oct 2007, Christian Couder wrote:
>
>> but I am not sure that the "dunno" logic should be the first part of it
>> to be done in C.
>
> The thing is, git-bisect is porcelain-ish. And by having a lot of the
> functionality there, which is not really porcelain, but plumbing, you
> prevent other porcelains, such as git-gui or qgit, from using that
> function.
>
> Which is bad.
Still, it is good to prototype in the script while figuring out
what the desired behaviour is, I would say.
What I was hoping to see when I posted --bisect-all suggestion
was a bit different from what Christian did, by the way.
In addition to the bisect/skip-* that are filtered at the shell
level, if you feed the list of commits that cannot be tested to
the bisection plumbing, you can affect the way the resulting
list from the --bisect-all is sorted.
Suppose you have this (B is bad, G is good):
o---.........---o---Y---o---o---B
/ /
G---o---.........---o---Z---X
and one round of bisection picked X. You find it untestable,
and Y and Z both bisects the remaining set equally well. In
such a case, the current code sorts the resulting set, with Y
and Z next to each other (because they are both closest to the
midway), and the Porcelain filters out X which is better than Y
or Z. You may end up picking Z.
Often, when X is not testable, neither is Z. We would be better
off to avoid checking a commit close to what are known to be
untestable while there are other commits that are equally close
to the midway.
So instead of sorting the list solely based on the mid-ness like
the current code does (i.e. compare_commit_dist()), we can tweak
commits' mid-ness value (i.e. best_bisection_sorted() computes
it in distance variable) by penalizing it with the closeness of
the commit to known untestable commits.
Naively, "closeness" of commit Z to commit X can be defined as
something simple as "rev-list Z...X | wc -l". The smaller the
number, the closer the commits.
^ permalink raw reply
* Re: [PATCH trailing ws fixed] use only the PATH for exec'ing gitcommands
From: Scott R Parish @ 2007-10-23 21:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071023211202.GA729@steel.home>
> Acked-by: Alex Riesen <raa.lkml@gmail.com>
>
> Don't forget to mention it needs the patch from Johannes re "deducing
> exec_path from calls to git with a relative path" and your
> "current_exec_path"-patch. Took me a while to figure these out...
Sorry about that! I was basing my patches off the head of spearce, as it
sounded like Junio was going to pick that stuff up.
sRp
^ permalink raw reply
* Re: [PATCH trailing ws fixed] use only the PATH for exec'ing git commands
From: Alex Riesen @ 2007-10-23 21:12 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071023040844.GQ16291@srparish.net>
Scott Parish, Tue, Oct 23, 2007 06:08:45 +0200:
> We need to correctly set up PATH for non-c based git commands. Since we
> already do this, we can just use that PATH and execvp, instead of looping
> over the paths with execve.
>
> This patch adds a setup_path() function to exec_cmd.c, which sets
> the PATH order correctly for our search order. execv_git_cmd() is
> stripped down to setting up argv and calling execvp(). git.c's main()
> only only needs to call setup_path().
>
> Signed-off-by: Scott R Parish <srp@srparish.net>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Don't forget to mention it needs the patch from Johannes re "deducing
exec_path from calls to git with a relative path" and your
"current_exec_path"-patch. Took me a while to figure these out...
^ permalink raw reply
* [PATCH] revert/cherry-pick: work on merge commits as well
From: Junio C Hamano @ 2007-10-23 20:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: martin f krafft, git discussion list
In-Reply-To: <alpine.LFD.0.999.0710231247301.30120@woody.linux-foundation.org>
Usually you cannot revert a merge because you do not know which
side of the merge should be considered the mainline (iow, what
change to reverse).
With this patch, cherry-pick and revert learn -m (--mainline)
option that lets you specify the parent number (starting from 1)
of the mainline, so that you can:
git revert -m 1 $merge
to reverse the changes introduced by the $merge commit relative
to its first parent, and:
git cherry-pick -m 2 $merge
to replay the changes introduced by the $merge commit relative
to its second parent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 23 Oct 2007, Junio C Hamano wrote:
>>
>> Desire to revert an octopus would, as you demonstrated, often be
>> to revert only one arm, but I think allowing to revert a twohead
>> merge should be trivial. If we define "reverting a merge" to
>> always revert all arms, then this should suffice.
>
> The only reason I don't like this is that it kind of assumes that the
> mainline is the first parent.
>
> Maybe I'd like to revert a merge, but I want to revert a merge that
> somebody *else* did, and maybe it was the first-hand parent I don't like.
>
> Those kinds of issues don't exist with non-merge commits: there's never
> any question "which side" to revert.
Fair enough. How about this?
Documentation/git-cherry-pick.txt | 9 +++++++-
Documentation/git-revert.txt | 9 +++++++-
builtin-revert.c | 42 ++++++++++++++++++++++++++++++------
git-compat-util.h | 13 +++++++++++
4 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 76a2edf..937c4a7 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
SYNOPSIS
--------
-'git-cherry-pick' [--edit] [-n] [-x] <commit>
+'git-cherry-pick' [--edit] [-n] [-m parent-number] [-x] <commit>
DESCRIPTION
-----------
@@ -44,6 +44,13 @@ OPTIONS
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
+-m parent-number|--mainline parent-number::
+ Usually you cannot revert a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows cherry-pick to replay the change
+ relative to the specified parent.
+
-n|--no-commit::
Usually the command automatically creates a commit with
a commit log message stating which commit was
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 69db498..3457c40 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -7,7 +7,7 @@ git-revert - Revert an existing commit
SYNOPSIS
--------
-'git-revert' [--edit | --no-edit] [-n] <commit>
+'git-revert' [--edit | --no-edit] [-n] [-m parent-number] <commit>
DESCRIPTION
-----------
@@ -27,6 +27,13 @@ OPTIONS
message prior committing the revert. This is the default if
you run the command from a terminal.
+-m parent-number|--mainline parent-number::
+ Usually you cannot revert a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows revert to reverse the change
+ relative to the specified parent.
+
--no-edit::
With this option, `git-revert` will not start the commit
message editor.
diff --git a/builtin-revert.c b/builtin-revert.c
index a655c8e..bfed69d 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -19,9 +19,9 @@
* Copyright (c) 2005 Junio C Hamano
*/
-static const char *revert_usage = "git-revert [--edit | --no-edit] [-n] <commit-ish>";
+static const char *revert_usage = "git-revert [--edit | --no-edit] [-n] [-m parent-number] <commit-ish>";
-static const char *cherry_pick_usage = "git-cherry-pick [--edit] [-n] [-r] [-x] <commit-ish>";
+static const char *cherry_pick_usage = "git-cherry-pick [--edit] [-n] [-m parent-number] [-r] [-x] <commit-ish>";
static int edit;
static int replay;
@@ -29,6 +29,7 @@ static enum { REVERT, CHERRY_PICK } action;
static int no_commit;
static struct commit *commit;
static int needed_deref;
+static int mainline;
static const char *me;
@@ -58,6 +59,12 @@ static void parse_options(int argc, const char **argv)
else if (!strcmp(arg, "-x") || !strcmp(arg, "--i-really-want-"
"to-expose-my-private-commit-object-name"))
replay = 0;
+ else if (!strcmp(arg, "-m") || !strcmp(arg, "--mainline")) {
+ if (++i >= argc ||
+ strtol_i(argv[i], 10, &mainline) ||
+ mainline <= 0)
+ usage(usage_str);
+ }
else if (strcmp(arg, "-r"))
usage(usage_str);
}
@@ -234,7 +241,7 @@ static int merge_recursive(const char *base_sha1,
static int revert_or_cherry_pick(int argc, const char **argv)
{
unsigned char head[20];
- struct commit *base, *next;
+ struct commit *base, *next, *parent;
int i;
char *oneline, *reencoded_message = NULL;
const char *message, *encoding;
@@ -269,8 +276,29 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!commit->parents)
die ("Cannot %s a root commit", me);
- if (commit->parents->next)
- die ("Cannot %s a multi-parent commit.", me);
+ if (commit->parents->next) {
+ /* Reverting or cherry-picking a merge commit */
+ int cnt;
+ struct commit_list *p;
+
+ if (!mainline)
+ die("Commit %s is a merge but no -m option was given.",
+ sha1_to_hex(commit->object.sha1));
+
+ for (cnt = 1, p = commit->parents;
+ cnt != mainline && p;
+ cnt++)
+ p = p->next;
+ if (cnt != mainline || !p)
+ die("Commit %s does not have parent %d",
+ sha1_to_hex(commit->object.sha1), mainline);
+ parent = p->item;
+ } else if (0 < mainline)
+ die("Mainline was specified but commit %s is not a merge.",
+ sha1_to_hex(commit->object.sha1));
+ else
+ parent = commit->parents->item;
+
if (!(message = commit->buffer))
die ("Cannot get commit message for %s",
sha1_to_hex(commit->object.sha1));
@@ -299,14 +327,14 @@ static int revert_or_cherry_pick(int argc, const char **argv)
char *oneline_body = strchr(oneline, ' ');
base = commit;
- next = commit->parents->item;
+ next = parent;
add_to_msg("Revert \"");
add_to_msg(oneline_body + 1);
add_to_msg("\"\n\nThis reverts commit ");
add_to_msg(sha1_to_hex(commit->object.sha1));
add_to_msg(".\n");
} else {
- base = commit->parents->item;
+ base = parent;
next = commit;
set_author_ident_env(message);
add_message_to_msg(message);
diff --git a/git-compat-util.h b/git-compat-util.h
index f23d934..a12c36b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -376,4 +376,17 @@ static inline int strtoul_ui(char const *s, int base, unsigned int *result)
return 0;
}
+static inline int strtol_i(char const *s, int base, int *result)
+{
+ long ul;
+ char *p;
+
+ errno = 0;
+ ul = strtol(s, &p, base);
+ if (errno || *p || p == s || (int) ul != ul)
+ return -1;
+ *result = ul;
+ return 0;
+}
+
#endif
--
1.5.3.4.1324.ga7925
^ permalink raw reply related
* Re: Howto request: going home in the middle of something?
From: Matthias Kestenholz @ 2007-10-23 20:28 UTC (permalink / raw)
To: Jing Xue; +Cc: Jan Wielemaker, Petr Baudis, git
In-Reply-To: <20071023135655.x6g6mln1j4880wog@intranet.digizenstudio.com>
Hi,
On 23.10.2007, at 19:56, Jing Xue wrote:
> What does the extra branch gain for us here? That's not a
> rhetorical question, I'm actually curious to learn, because I
> always just commit, switch to another computer, pull, and reset HEAD^.
If someone tracks the main branch you are working on and fetches
while you are travelling home, he has the WIP commit as a new tip
in his tree.
If he bases further work upon the WIP commit, he'll need to rebase
or merge his changes onto your new tip once you have amended or
replaced the commit. If you are working on the
master branch, you should really avoid rewinding it. Rewinding topic
branches is ok, but a temporary branch is still better to clearly tell
potential fetch-ers that this is only Work in Progress, and not meant
to be published in the current state.
Matthias
--
http://spinlock.ch/blog/
^ 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