Feature request: git-pull -e/--edit

Feature request: git-pull -e/--edit

[linux]

The last end-user use I can think of for git-merge instead
of git-pull is providing a custom commit message.

Would it be possible to add -m and -e options to git-pull?

The problem I can see is that the latter would have to be added to
git-merge, and the guts there are a bit intricate; it uses git-commit-tree
directly rather than git-commit, so I can't just pass through the
arguments.

Assuming it's just as much of a pain for someone else, would it
still be worth the effort?  Can git-merge be cleaned up?

The manual option is to use "git merge --no-commit" and then supply the
arguments to git-commit in the usual way.

But I notice that --no-commit actually changes git's merging
technique.  If it's specified, the trivial in-index merge doesn't
appear to be attempted.  I don't think it makes a huge difference,

Re: Feature request: git-pull -e/--edit

[Junio C Hamano]

linux@horizon.com writes:

> The last end-user use I can think of for git-merge instead
> of git-pull is providing a custom commit message.
>
> Would it be possible to add -m and -e options to git-pull?
>
> The problem I can see is that the latter would have to be added to
> git-merge, and the guts there are a bit intricate; it uses git-commit-tree
> directly rather than git-commit, so I can't just pass through the
> arguments.

How often is this desired, when the merge is clean?  

If the answer is "not so often", you can already use "commit
--amend" after "pull" creates an automated merge commit.

Re: Feature request: git-pull -e/--edit

[linux]

> How often is this desired, when the merge is clean?  

Well, if I could quote your own words:

>> I use "git pull . topicA topicB" for a tetrapus, so that is not
>> a reason for me, but when a topicA's older parts are worthy to
>> be in 'next' while later parts are not yet, I often do (on 'next'):
>> 
>>	git merge "Merge early part of branch 'topicA'" HEAD topicA~3

I can't speak from personal experience, but a merge can bring in a lot
of changes, and sometimes the auto-generated message doesn't say quite
as much as you'd like.

The commits on the branch speak for themselves, of course, but sometimes
it's nice to add the same sort of overview that appears in a [PATCH 0/13]
e-mail.  We wouldn't have that convention if there wasn't a frequent
desire for it.

(Indeed, it might be nice to come up with a way of including a piece of
the "please pull" e-mail, similar to the way that git-applypatch works.)

> If the answer is "not so often", you can already use "commit
> --amend" after "pull" creates an automated merge commit.

It's not done very often right now, but how much of that is due to
the awkwardness?  I agree it works perfectly, but "commit --amend"
has very much the feel of a workaround.

I'm not going to besiege Troy for a decade over the idea, but it seemed

Re: Feature request: git-pull -e/--edit

[Junio C Hamano]

linux@horizon.com writes:

>> How often is this desired, when the merge is clean?  
>
> Well, if I could quote your own words:
>
>>> I use "git pull . topicA topicB" for a tetrapus, so that is not
>>> a reason for me, but when a topicA's older parts are worthy to
>>> be in 'next' while later parts are not yet, I often do (on 'next'):
>>> 
>>>	git merge "Merge early part of branch 'topicA'" HEAD topicA~3
>
> I can't speak from personal experience, but a merge can bring in a lot
> of changes, and sometimes the auto-generated message doesn't say quite
> as much as you'd like.

That is more or less irrelevant example.  I was only saying that
it is a workaround to emulate "git pull . topicA~3"; if that
form worked, I would keep the automated fmt-merge-msg output
that is currently recorded in the merge and I do not see any
need to edit it further.

> (Indeed, it might be nice to come up with a way of including a piece of
> the "please pull" e-mail, similar to the way that git-applypatch works.)

That is a lot more relevant example.  For example, I could
imagine that Linus coming up with a wrapper that is fed a series
of e-mails and:

 * if it is a patch, run git-applymbox on it as before,

 * if it is a pull request, then extract the URL and branch, run
   "git pull" on that, match the "diff ORIG_HEAD" output against
   what is in the pull request and,

   - warn if there are huge discrepancies;

   - otherwise annotate the commit message with the explanation
     of the series taken from the pull request message.

But even in that workflow, "annotate the commit" comes after
pull happens and the merge result is verified, so I do not quite
see "commit --amend" as a "workaround" as you said.

Having said that, I think the real reason that the whole "merge"
message generation feels awkward comes from the historical
division of labor between pull and merge.

"git merge" started its life as the first level command (with a
funny syntax that does not even take command line option -m,
because you are supposed to give the whole merge message and
"git merge" itself does not do anything to affect the merge
message on its own).  When it was pushed further back to the
"worker behind the scene" status, the task of coming up with a
fancier automated merge message were still left to the "git
pull" command which (1) is the UI level command that the users
are expected to use, and (2) knows much more about the context
where the merge is generated than "git merge" itself.  As a
result, "git merge" still takes the whole message prepared and
it does not do anything on its own.

So if we rename the current "git merge" to "git-merge--record"
(or any name "git pull" uses internally to record the merge
commit), and make "git merge" a synonym to "git pull .", and
give a command line option -m to "git pull" to _affect_ the
resulting merge message, I would think everybody would become
quite happy.  It means:

 - People can say "git merge this-branch" (which is internally
   translated to "git pull . this-branch");

 - People can say "git pull -m 'I am doing this merge for such
   and such reason' $URL $branch" to _include_ that message in
   the resulting merge commit;

 - The same can be said about "git merge -m 'comment' $branch".

I said _affect_ and _include_ in the above because I suspect
that most of the time you do not want to _replace_ the
autogenerated part ("Merge branch of repo", and if you are
pulling from your subordinate trees the merge summary message as
well).

Re: Feature request: git-pull -e/--edit

[Jakub Narebski]

Junio C Hamano wrote:

> So if we rename the current "git merge" to "git-merge--record"

or git-merge-driver

> (or any name "git pull" uses internally to record the merge
> commit), and make "git merge" a synonym to "git pull .", and
> give a command line option -m to "git pull" to _affect_ the
> resulting merge message, I would think everybody would become
> quite happy.  It means:
> 
>  - People can say "git merge this-branch" (which is internally
>    translated to "git pull . this-branch");
> 
>  - People can say "git pull -m 'I am doing this merge for such
>    and such reason' $URL $branch" to _include_ that message in
>    the resulting merge commit;
> 
>  - The same can be said about "git merge -m 'comment' $branch".
> 
> I said _affect_ and _include_ in the above because I suspect
> that most of the time you do not want to _replace_ the
> autogenerated part ("Merge branch of repo", and if you are
> pulling from your subordinate trees the merge summary message as
> well).

I'm all for adding -m <msg> option to git-pull (and perhaps also common
other message generation options: -F <file>, --edit). I'm even for adding
-m option to git-merge. 

Making "git merge" to be a synonym to "git pull ."... I'm not so sure.
I'd rather we don't lose the ability to give arbitrary refs ar "other"
heads like in

  git merge "Merge early part of branch 'topicA'" HEAD topicA~3

example, and ability (if there is such ability) to not include HEAD (current
version of branch) as first parent like in

  git checkout pu
  git merge "Merge branch 'topicA', 'topicB'" topicA topicB

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

[PATCH] git-merge: make it usable as the first class UI

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> So if we rename the current "git merge" to "git-merge--record"
> (or any name "git pull" uses internally to record the merge
> commit), and make "git merge" a synonym to "git pull .", and
> give a command line option -m to "git pull" to _affect_ the
> resulting merge message, I would think everybody would become
> quite happy.  It means:
>
>  - People can say "git merge this-branch" (which is internally
>    translated to "git pull . this-branch");
>
>  - People can say "git pull -m 'I am doing this merge for such
>    and such reason' $URL $branch" to _include_ that message in
>    the resulting merge commit;
>
>  - The same can be said about "git merge -m 'comment' $branch".
>
> I said _affect_ and _include_ in the above because I suspect
> that most of the time you do not want to _replace_ the
> autogenerated part ("Merge branch of repo", and if you are
> pulling from your subordinate trees the merge summary message as
> well).

I did a moral equivalent of the above without renaming the
command "git merge" and will be pushing the result out in "pu"
shortly.

The following is for commenting only -- it depends on an earlier
patch in "pu".

-- >8 --
[PATCH] git-merge: make it usable as the first class UI

This teaches the oft-requested syntax

	git merge $commit

to implement merging the named commit to the current branch.
This hopefully would make "git merge" usable as the first class
UI instead of being a mere backend for "git pull".

Most notably, $commit above can be any committish, so you can
say for example:

	git merge js/shortlog~2

to merge early part of a topic branch without merging the rest
of it.

A custom merge message can be given with the new --message=<msg>
parameter.  The message is prepended in front of the usual
"Merge ..." message autogenerated with fmt-merge-message.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/git-merge.txt |   18 +++++++++---
 git-merge.sh                |   61 ++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index bebf30a..e2954aa 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -8,12 +8,14 @@ git-merge - Grand Unified Merge Driver
 
 SYNOPSIS
 --------
-'git-merge' [-n] [--no-commit] [-s <strategy>]... <msg> <head> <remote> <remote>...
-
+[verse]
+'git-merge' [-n] [--no-commit] [--squash] [-s <strategy>]...
+	[--reflog-action=<action>]
+	-m=<msg> <remote> <remote>...
 
 DESCRIPTION
 -----------
-This is the top-level user interface to the merge machinery
+This is the top-level interface to the merge machinery
 which drives multiple merge strategy scripts.
 
 
@@ -27,13 +29,19 @@ include::merge-options.txt[]
 	to give a good default for automated `git-merge` invocations.
 
 <head>::
-	our branch head commit.
+	Our branch head commit.  This has to be `HEAD`, so new
+	syntax does not require it
 
 <remote>::
-	other branch head merged into our branch.  You need at
+	Other branch head merged into our branch.  You need at
 	least one <remote>.  Specifying more than one <remote>
 	obviously means you are trying an Octopus.
 
+--reflog-action=<action>::
+	This is used internally when `git-pull` calls this command
+	to record that the merge was created by `pull` command
+	in the `ref-log` entry that results from the merge.
+
 include::merge-strategies.txt[]
 
 
diff --git a/git-merge.sh b/git-merge.sh
index 84c3acf..25deb1e 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,8 @@
 # Copyright (c) 2005 Junio C Hamano
 #
 
-USAGE='[-n] [--no-commit] [--squash] [-s <strategy>]... <merge-message> <head> <remote>+'
+USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [--reflog-action=<action>] [-m=<merge-message>] <commit>+'
+
 . git-sh-setup
 
 LF='
@@ -92,7 +93,7 @@ finish () {
 
 case "$#" in 0) usage ;; esac
 
-rloga=
+rloga= have_message=
 while case "$#" in 0) break ;; esac
 do
 	case "$1" in
@@ -125,17 +126,63 @@ do
 	--reflog-action=*)
 		rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
 		;;
+	-m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
+		merge_msg=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+		have_message=t
+		;;
+	-m|--m|--me|--mes|--mess|--messa|--messag|--message)
+		shift
+		case "$#" in
+		1)	usage ;;
+		esac
+		merge_msg="$1"
+		have_message=t
+		;;
 	-*)	usage ;;
 	*)	break ;;
 	esac
 	shift
 done
 
-merge_msg="$1"
-shift
-head_arg="$1"
-head=$(git-rev-parse --verify "$1"^0) || usage
-shift
+# This could be traditional "merge <msg> HEAD <commit>..."  and the
+# way we can tell it is to see if the second token is HEAD, but some
+# people might have misused the interface and used a committish that
+# is the same as HEAD there instead.  Traditional format never would
+# have "-m" so it is an additional safety measure to check for it.
+
+if test -z "$have_message" &&
+	second_token=$(git-rev-parse --verify "$2^0" 2>/dev/null) &&
+	head_commit=$(git-rev-parse --verify "HEAD" 2>/dev/null) &&
+	test "$second_token" = "$head_commit"
+then
+	merge_msg="$1"
+	shift
+	head_arg="$1"
+	shift
+else
+	# We are invoked directly as the first-class UI.
+	head_arg=HEAD
+
+	# All the rest are the commits being merged; prepare
+	# the standard merge summary message to be appended to
+	# the given message.  If remote is invalid we will die
+	# later in the common codepath so we discard the error
+	# in this loop.
+	merge_name=$(for remote
+		do
+			rh=$(git-rev-parse --verify "$remote"^0 2>/dev/null)
+			if git show-ref -q --verify "refs/heads/$remote"
+			then
+				what=branch
+			else
+				what=commit
+			fi
+			echo "$rh		$what '$remote'"
+		done | git-fmt-merge-msg
+	)
+	merge_msg="${merge_msg:+$merge_msg$LF$LF}$merge_name"
+fi
+head=$(git-rev-parse --verify "$head_arg"^0) || usage
 
 # All the rest are remote heads
 test "$#" = 0 && usage ;# we need at least one remote head.
-- 
1.4.4.gbacc

Re: [PATCH] git-merge: make it usable as the first class UI

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:

[...]

> -- >8 --
> [PATCH] git-merge: make it usable as the first class UI
> 
> This teaches the oft-requested syntax
> 
> 	git merge $commit
> 
> to implement merging the named commit to the current branch.
> This hopefully would make "git merge" usable as the first class
> UI instead of being a mere backend for "git pull".
> 
> Most notably, $commit above can be any committish, so you can
> say for example:
> 
> 	git merge js/shortlog~2
> 
> to merge early part of a topic branch without merging the rest
> of it.

"Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one
commit?

> A custom merge message can be given with the new --message=<msg>
> parameter.  The message is prepended in front of the usual
> "Merge ..." message autogenerated with fmt-merge-message.

Why not -m too (consistency!)?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

Re: [PATCH] git-merge: make it usable as the first class UI

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

>> Most notably, $commit above can be any committish, so you can
>> say for example:
>> 
>> 	git merge js/shortlog~2
>> 
>> to merge early part of a topic branch without merging the rest
>> of it.
>
> "Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one
> commit?

"Early part up to that commit" -- this is not a cherry pick.

>> A custom merge message can be given with the new --message=<msg>
>> parameter.  The message is prepended in front of the usual
>> "Merge ..." message autogenerated with fmt-merge-message.
>
> Why not -m too (consistency!)?

That form also is accepted, I think.

Re: Feature request: git-pull -e/--edit

[Eran Tromer]

On 2006-11-20 05:21, Junio C Hamano wrote:
> linux@horizon.com writes:

>> (Indeed, it might be nice to come up with a way of including a piece of
>> the "please pull" e-mail, similar to the way that git-applypatch works.)
> 
> That is a lot more relevant example.  For example, I could
> imagine that Linus coming up with a wrapper that is fed a series
> of e-mails and:
> 
[snip]
>    - otherwise annotate the commit message with the explanation
>      of the series taken from the pull request message.
[snip]
>  - People can say "git pull -m 'I am doing this merge for such
>    and such reason' $URL $branch" to _include_ that message in
>    the resulting merge commit;
> 
>  - The same can be said about "git merge -m 'comment' $branch".


What about fast forwards? Do you get to record the explanation for the
series only if the guy you pulled from didn't bother to do a rebase?
That's broken.

Let's face it, the merge commits generated when pulling have two
completely independent uses:
1. They're technically necessary for joining DAG nodes that don't all
   lie on one path.
2. They're useful as a record of workflow and a place to put comments.

The two uses are nearly independent.
Consider the following silly DAG.

  A------------F master
   \          /
    B--C--D--E

Yes, E and F have identical trees. But it's actually *very useful*, if
the commit message at F says "merged branch foo containing experimental
bar from quux". And it shows up nicely when looking at gitk.

Of course, you could just fast-forward instead:

  A--B--C--D--E master

but then you lose a meaningful and useful part of the historical record.

There are the obvious bad consequences if you make this the default,
but how about adding a --force-commit option to merge and pull?

You'd need to educate users on how to use this responsibly to avoid
noise, but that's not any different from existing stuff like rebase and
revert. Most users won't even know it exists.

And to answer Linus: yes, it's expected that only non-leaf developers
will use --force-commit on regular basis, but that's not because
maintainers are technically special in any way. It's just because
maintainers have something useful to say ("someone's private topic
branch, starting at A and ending at E, has just been accepted into my
all-important public repo and here's why"). Anyone else can do the same
if he feels likewise.

Re: Feature request: git-pull -e/--edit

[Horst H. von Brand]

Eran Tromer <git2eran@tromer.org> wrote:

[...]

> What about fast forwards? Do you get to record the explanation for the
> series only if the guy you pulled from didn't bother to do a rebase?
> That's broken.
> 
> Let's face it, the merge commits generated when pulling have two
> completely independent uses:
> 1. They're technically necessary for joining DAG nodes that don't all
>    lie on one path.
> 2. They're useful as a record of workflow and a place to put comments.
> 
> The two uses are nearly independent.
> Consider the following silly DAG.
> 
>   A------------F master
>    \          /
>     B--C--D--E
> 
> Yes, E and F have identical trees. But it's actually *very useful*, if
> the commit message at F says "merged branch foo containing experimental
> bar from quux". And it shows up nicely when looking at gitk.

I don't see the usefulness of this. 

> Of course, you could just fast-forward instead:
> 
>   A--B--C--D--E master

Yep.

> but then you lose a meaningful and useful part of the historical record.

And if quux merges back, she gets the same plus a new merge node, and...
Linus told everybody (quite forcefully, I might add) that this is not
acceptable for distributed development.

> There are the obvious bad consequences if you make this the default,
> but how about adding a --force-commit option to merge and pull?

Fast forward is fast forward. Merge is when /independent/ changes are
integrated into one.

> You'd need to educate users on how to use this responsibly

Looks like you've never met real users ;-)

>                                                            to avoid
> noise, but that's not any different from existing stuff like rebase and
> revert. Most users won't even know it exists.

> And to answer Linus: yes, it's expected that only non-leaf developers
> will use --force-commit on regular basis, but that's not because
> maintainers are technically special in any way. It's just because
> maintainers have something useful to say ("someone's private topic
> branch, starting at A and ending at E, has just been accepted into my
> all-important public repo and here's why"). Anyone else can do the same
> if he feels likewise.

But the individual changes will presumably reflect said someone's
authorship. If they are interleaved with stuff by others or not doesn't
make much (development) sense. Yes, it might be interesting for a software
historian, but that's not git's main audience in the first place.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

Re: Feature request: git-pull -e/--edit

[Petr Baudis]

On Mon, Nov 20, 2006 at 06:09:50PM CET, Horst H. von Brand wrote:
> Eran Tromer <git2eran@tromer.org> wrote:
> >   A------------F master
> >    \          /
> >     B--C--D--E
..snip..
> And if quux merges back, she gets the same plus a new merge node, and...
> Linus told everybody (quite forcefully, I might add) that this is not
> acceptable for distributed development.

Wrong, if quux merges back and does not do the same "force commit"
fast-forward (why would it, anyway - OP clearly said it's only if you
_want_ to make it explicit), quux won't get another merge but end up
with F as well. It all converges back nicely.

I can see how it could be useful.

> > You'd need to educate users on how to use this responsibly
> 
> Looks like you've never met real users ;-)

Yes, that is a real problem. ;-) But not adding features because users
could use them irresponsibly doesn't get you too far.

> > And to answer Linus: yes, it's expected that only non-leaf developers
> > will use --force-commit on regular basis, but that's not because
> > maintainers are technically special in any way. It's just because
> > maintainers have something useful to say ("someone's private topic
> > branch, starting at A and ending at E, has just been accepted into my
> > all-important public repo and here's why"). Anyone else can do the same
> > if he feels likewise.
> 
> But the individual changes will presumably reflect said someone's
> authorship.

You are personifying too much. Git setups where multiple people have
commit access are very common, and there's no reason to play them down
just because Git makes other setups easy.

> If they are interleaved with stuff by others or not doesn't make much
> (development) sense. Yes, it might be interesting for a software
> historian, but that's not git's main audience in the first place.

Tell that to Junio, our pickaxe guy. :^)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."

Re: Feature request: git-pull -e/--edit

[Eran Tromer]

On 2006-11-20 19:09, Horst H. von Brand wrote:
>>
>>   A------------F master
>>    \          /
>>     B--C--D--E
>>
>> Yes, E and F have identical trees. But it's actually *very useful*, if
>> the commit message at F says "merged branch foo containing experimental
>> bar from quux". And it shows up nicely when looking at gitk.
> 
> I don't see the usefulness of this. 

Just look up this thread for the most recent example: recording the text
of "pull foo to get" and "[00/05] Fix quux" message.


> And if quux merges back, she gets the same plus a new merge node, and...
> Linus told everybody (quite forcefully, I might add) that this is not
> acceptable for distributed development.

I've address this. Sure, it breaks down completely if done by default
when nothing new happens; but not when done judiciously. For real
problems to show up you'd need two people who both insist on always
using --force-commit when pulling each other. Inevitably, before long
they will realize the folly of their ways and stop doing that; problem
solved.

I expect common usage to be that --force-commit is only used by
maintainers, when pulling/applying non-trivial branches from downstream.
But this is a social convention that can be decided per project, and can
be ignored by anyone who decides to fork off. And if Linus doesn't like
it he can just avoid using it in his projects.


>> There are the obvious bad consequences if you make this the default,
>> but how about adding a --force-commit option to merge and pull?
> 
> Fast forward is fast forward. Merge is when /independent/ changes are
> integrated into one.

I was under the impression that git-merge is what (indirectly)
determines if joining multiple commits is a fast-forward or a real
merge. If it's in some other piece of git, please substitute that.


>> You'd need to educate users on how to use this responsibly
> 
> Looks like you've never met real users ;-)

No, it's really easy in this case: if someone asks you to pull a rotten
branch with too many forced merges, just refuse until he stops abusing
that option. It's not the default, right? There are plenty of much worse
non-default ways to damage history.


>> And to answer Linus: yes, it's expected that only non-leaf developers
>> will use --force-commit on regular basis, but that's not because
>> maintainers are technically special in any way. It's just because
>> maintainers have something useful to say ("someone's private topic
>> branch, starting at A and ending at E, has just been accepted into my
>> all-important public repo and here's why"). Anyone else can do the same
>> if he feels likewise.
> 
> But the individual changes will presumably reflect said someone's
> authorship. If they are interleaved with stuff by others or not doesn't
> make much (development) sense. Yes, it might be interesting for a software
> historian, but that's not git's main audience in the first place.

If the only thing you care about is the tree of the top commit, then
sure, those redundant commits are worthless. But then, why do you bother
with (for example) commit messages, or tag objects? Oh, you want to know
more about what happened and why? Then great, those "pull foo to get"
and "[00/05]" messages are probably the best place to start, if we only
had where to save them.

We are all "software historians" when we look at some project's public
branches and try to grok what's going on recently, who's doing what and
along what workflow, and why it got there. This is useful information,
that is not easily tracked by any other means; there's a reason this
comes up repeatedly in various guises, you know. I can't see why some
people are so eager to discard this information and tell others to use a
munged-up shortlogs, instead of looking for ways to record as much
possible with the least negative impact.

Now, --force-commit with appropriate usage conventions seems like a
reasonable tradeoff.

BTW, in principle another (better?) way to do it is by leaving the
commit DAG alone, and annotating it with tag objects where extra
information such as "[00/05]" is available. The problem is that git
doesn't have any scalable mechanism for adding such annotations. It's a
hard problem; nothing in the commit DAG points to to tag objects, so you
have to scan some external store and that gets more expensive as the
repo grows. It also gets nasty in fetches.

  Eran

Re: Feature request: git-pull -e/--edit

[Johannes Schindelin]

Hi,

On Mon, 20 Nov 2006, Eran Tromer wrote:

> On 2006-11-20 19:09, Horst H. von Brand wrote:
> >>
> >>   A------------F master
> >>    \          /
> >>     B--C--D--E
> >>
> >> Yes, E and F have identical trees.

There has been only _one_ line of history, so why introduce what was not 
there?

It sounds more like you do not trust "E" to be something especially 
useful, but in that case you should not merge it to begin with.

Ciao,

Re: Feature request: git-pull -e/--edit

[Junio C Hamano]

linux@horizon.com writes:

> But I notice that --no-commit actually changes git's merging
> technique.  If it's specified, the trivial in-index merge doesn't
> appear to be attempted.  I don't think it makes a huge difference,
> but is any difference desirable?

This was done in response to a specific request from the list
but I do not remember the details.  If I were to research the
background I would

 (1) first, look at the authordate of the commit that introduced
     the change.  For this, I would most likely use:

	git log -p -S--no-commit -- git-pull.sh

 (2) go back to the list archive and find the thread that
     predates that commit by a few days.