* Re: An alternate model for preparing partial commits
From: Junio C Hamano @ 2008-06-27 23:14 UTC (permalink / raw)
To: Robert Anderson; +Cc: David Jeske, Jakub Narebski, git
In-Reply-To: <9af502e50806271555j3cd06ecau122b11217f612217@mail.gmail.com>
"Robert Anderson" <rwa000@gmail.com> writes:
> There are good reasons for desiring a workflow that does not routinely
> change history as part of the usual workflow. Maybe there are clones
> of your repo. Maybe as part of your workflow discipline you do not
> want HEAD states that cannot be pushed to public, because you don't
> want to manually keep track of when it is ok and when it is not ok to
> push HEAD to public, since git cannot tell you this.
Surely you can arrange that. You keep track of what you pushed out, and
you refrain from rebasing beyond that point.
And fast-forward check in the push to the public will notice if you break
that "workflow discipline" by accident.
^ permalink raw reply
* Re: Adding a 'version' command to the server
From: Junio C Hamano @ 2008-06-27 23:15 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <486572BC.9070201@gmail.com>
Lea Wiemann <lewiemann@gmail.com> writes:
> Junio C Hamano wrote:
>
>> It is still possible to connect to older remote end with new clients, but
>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>> option when running "git fetch"
>
> Now that the current git won't work with older servers anyway,...
Whoa, Wait. Who said that?
^ permalink raw reply
* Re: Adding a 'version' command to the server
From: Lea Wiemann @ 2008-06-27 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej6io4fy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Lea Wiemann <lewiemann@gmail.com> writes:
>> Junio C Hamano wrote:
>>> It is still possible to connect to older remote end with new clients, but
>>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>>> option when running "git fetch"
>>
>> Now that the current git won't work with older servers anyway,...
>
> Whoa, Wait. Who said that?
I meant "now that the current git won't work with *some* older servers
*without adding an option*". Or did I misunderstand you?
-- Lea
^ permalink raw reply
* Re: [EGIT PATCH 00/23] Push implementation
From: Robin Rosenberg @ 2008-06-27 23:25 UTC (permalink / raw)
To: Marek Zawirski; +Cc: spearce, git
In-Reply-To: <1214604407-30572-1-git-send-email-marek.zawirski@gmail.com>
lördagen den 28 juni 2008 00.06.24 skrev Marek Zawirski:
> Finally, series with push implementation. It has taken a "while" to
> squash all bugs this time and polish the series, uhh.
This will make fine weekend reading :)
-- robin
^ permalink raw reply
* Re: bug related to branches using / in name
From: Junio C Hamano @ 2008-06-27 23:31 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <20080627035747.GC7144@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jun 26, 2008 at 11:02:46PM -0400, Jeff King wrote:
>
>> It might be nicer if this were handled automatically, but it would
>> violate git-fetch's rule about never deleting branches.
Hmm. Is there actually such a rule?
I was wondering if it might make more sense to do the equivalent of what
checkout_entry() does (i.e. remove_subtree()) when there is such a
conflict. After all, tracking branches are meant to accept rewinds and
anything that happens on the remote end, and having to run "git remote
prune" is not a feature but is a lack of feature in the "git fetch", which
may make it look like deletion is somewhat special.
^ permalink raw reply
* Re: [PATCH] fetch: report local storage errors in status table
From: Junio C Hamano @ 2008-06-27 23:37 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <20080627035950.GA21382@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Previously, if there was an error while storing a local
> tracking ref, the low-level functions would report an error,
> but fetch's status output wouldn't indicate any problem.
> E.g., imagine you have an old "refs/remotes/origin/foo/bar" but
> upstream has deleted "foo/bar" in favor of a new branch
> "foo". You would get output like this:
>
> error: there are still refs under 'refs/remotes/origin/foo'
> From $url_of_repo
> * [new branch] foo -> origin/foo
>
> With this patch, the output takes into account the status of
> updating the local ref:
>
> error: there are still refs under 'refs/remotes/origin/foo'
> From $url_of_repo
> ! [new branch] foo -> origin/foo (unable to update local ref)
>
> Signed-off-by: Jeff King <peff@peff.net>
Makes sense --- thanks. This is something we can have automated tests,
isn't it?
^ permalink raw reply
* Re: 'next' will be rewound shortly
From: Stephan Beyer @ 2008-06-27 23:41 UTC (permalink / raw)
To: Miklos Vajna, gitster; +Cc: git
In-Reply-To: <20080627213605.GD2058@genesis.frugalware.org>
Hi,
> <gitster@pobox.com> wrote:
> > Following git tradition, manpage came after the command's behaviour has
> > been long established. It will be a behaviour change, and it is open to
> > debate if the new behaviour is better or if the proposed change of
> > behaviour hurts existing users.
>
> If my opinion counts, I like the current ("prepend") one, and I think
> the best would be to add a new option (and/or make it configurable) for
> the new ("replace") one.
Well, perhaps I am different, but I sometimes have temporary branches
named like "first-silly-experiment" and I do not expect having a
Merge branch 'another-silly-experiment' into 'first-silly-experiment'
appended, when I do a
git merge -m "Merge a lot of useful stuff... blabla" another-silly-experiment.
(btw, I don't *really* name my branches like this..it's just an example.)
Well, I see this from a "sequencer author point of view", where
merge silly-experiment
will invoke an editor,
merge --standard silly-experiment
generates some kind of the typical standard (or default) message,
and
merge --message "Merge blabla" silly-experiment
does the "obvious". (For me this is the obvious since I've never
experienced another behavior. All my merges have been using the
now disappeared commit.)
So I'd vote for a "replace" behavior by default on -m, and an
"append standard message" option, but if there is *one* person
who relies on the prepend feature, I'd also take the "prepend"
default and would like to vote for an option that does the
replacement.
For the current state of the art, it seems that I have to merge
with whatever message and then do a commit -m "..." --amend.
Regards,
Stephan Beyer
PS: Currently using webmail. So sorry for any too long lines
or whatever.
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
^ permalink raw reply
* Re: Installation Guide
From: Robin Rosenberg @ 2008-06-27 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Chris Hapgood, git
In-Reply-To: <alpine.DEB.1.00.0806271543090.9925@racer>
fredagen den 27 juni 2008 16.43.24 skrev Johannes Schindelin:
> On Fri, 27 Jun 2008, Chris Hapgood wrote:
>
> > FYI, I have posted a noob installation guide for Egit here:
> > http://cho.hapgoods.com/wordpress/?p=159
Excellent! Thanks.
>
> Added to the Wiki.
Added twice, to the Eclipse plugin page too.
-- robin
^ permalink raw reply
* Re: 'next' will be rewound shortly
From: Junio C Hamano @ 2008-06-28 0:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Stephan Beyer, git
In-Reply-To: <20080627213605.GD2058@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Fri, Jun 27, 2008 at 02:28:29PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> Following git tradition, manpage came after the command's behaviour has
>> been long established. It will be a behaviour change, and it is open to
>> debate if the new behaviour is better or if the proposed change of
>> behaviour hurts existing users.
>
> If my opinion counts, I like the current ("prepend") one,...
Well, I do not think you are alone --- otherwise the original behaviour
would not be such ;-)
In any case, what is more important is that the proposed change is a
change in behaviour and the burden of proof that it does not hurt people's
existing scripts is on the party that wants to change it.
^ permalink raw reply
* Re: [PATCH] git-apply doesn't handle same name patches well [V4]
From: Junio C Hamano @ 2008-06-28 0:06 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <1214591952-3763-1-git-send-email-dzickus@redhat.com>
Thanks. Looks much better. Will queue.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: しらいしななこ @ 2008-06-28 0:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Avery Pennarun, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <7vabh6plyh.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
>> Because it is where the convention that is used in all of the UI is
>> described, I think gitcli documentation is an appropriate place.
>
> I am still not convinced it is the best place but I guess it would be
> better than not documenting it anywhere.
>
>> Don't you also want to talk about distinction between --cached and
>> --index that new people are often confused about? These options are
>> defined consistently across commands but people who do not know it bring
>> up discussions to rename --cached to some commands to --index to make it
>> inconsistent and waste your time every once in a while.
Do you have any comment on the --index/--cached issue?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Jeske, Jakub Narebski, git
In-Reply-To: <7viqvuo4hq.fsf@gitster.siamese.dyndns.org>
On Fri, Jun 27, 2008 at 4:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Robert Anderson" <rwa000@gmail.com> writes:
>
>> There are good reasons for desiring a workflow that does not routinely
>> change history as part of the usual workflow. Maybe there are clones
>> of your repo. Maybe as part of your workflow discipline you do not
>> want HEAD states that cannot be pushed to public, because you don't
>> want to manually keep track of when it is ok and when it is not ok to
>> push HEAD to public, since git cannot tell you this.
>
> Surely you can arrange that. You keep track of what you pushed out, and
> you refrain from rebasing beyond that point.
First, the constraint of achieving this workflow when there are clones
of the repo in question removes any need for additional rationales.
That being said...
In the existing model which is being suggested as a way to get the
desired workflow, there are two distinct classes of commits: commits
that are "for real", and commits that are "temporary", that are being
used as some kind of workspace for orthogonalizing a set of changes,
which will eventually be replaced by "for real" commits. Yet git has
no metadata to distinguish these two types of commits. When only "for
real" commits exist, I can push HEAD. When "temporary" commits exist,
I cannot, or insidious problems will ensue. This metadata concerning
"for real" or "temporary" commits is only maintained manually in the
developer's head. But, this is the sort of thing that computers are
for, and should not be the burden of the developer to maintain this
information in his mental cache, especially when the price of making
an error can be quite high. It would be very easy to forget that you
intended to do more work on your last N commits, and push HEAD because
somebody asks you to make sure you've pushed your latest work. Your
tools should prevent this kind of scenario. Git cannot, because it
doesn't know what you intend when you "commit" because two different
ideas are being conflated with "commit" in this model.
In my proposed model, there is a clear distinction, kept track of by
git, not the developer, between changes which are in the "temporary
workspace" which is still being worked on, and changes which are "for
real", that can be shared, either through a push to a public repo or
if there are clones of my repo. They become "for real" when they are
committed. That's the purpose of a "commit" in this workflow. To
bless a change as ready for viewing by others, even if you do not want
to make it available yet (by a push to a public repo). I can walk
away from a working tree for six months, come back, and there can be
no confusion about which changes were "temporary" and possibly in need
of revision, and which changes are blessed as ready for public
consumption. If I come back to a branch on which there are several
commits which have not been pushed yet, how do I know which are
"temporary" and which are "for real" commits? I cannot. It is
impossible. The information is not there.
But, all of this is moot when you consider the simple case of a repo
which has been cloned, on which you'd like to make partial commits,
and test the committed state before doing so.
Thanks,
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: David Jeske @ 2008-06-28 0:22 UTC (permalink / raw)
To: Robert Anderson; +Cc: Jakub Narebski, git
In-Reply-To: <9af502e50806271555j3cd06ecau122b11217f612217@mail.gmail.com>
-- Robert Anderson wrote:
> Possibly a succinct way of moving this conversation forward is to say that:
>
> What is desired is a workflow where partial commits can be tested,
> when it is desirable not to change history.
Why don't we just make a model where history changes are handled safetly? Then
we don't have to be afraid to publish DAGs we may want to change later.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: David Jeske @ 2008-06-28 0:22 UTC (permalink / raw)
To: Robert Anderson; +Cc: Jakub Narebski, git
In-Reply-To: <9af502e50806271555j3cd06ecau122b11217f612217@mail.gmail.com>
-- Robert Anderson wrote:
> Possibly a succinct way of moving this conversation forward is to say that:
>
> What is desired is a workflow where partial commits can be tested,
> when it is desirable not to change history.
Why don't we just make a model where history changes are handled safetly? Then
we don't have to be afraid to publish DAGs we may want to change later.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Theodore Tso @ 2008-06-28 1:17 UTC (permalink / raw)
To: David Jeske; +Cc: Robert Anderson, Git Mailing List
On Fri, Jun 27, 2008 at 08:29:15PM -0000, David Jeske wrote:
> git has all the concepts I want except one. However, it makes the process
> pretty manual. Here is an idea about automating it. I'll talk about that one
> new concept at the bottom.
>
> I think of this as reorder/merge/split...
>
> reorder: Picture that a list of commits on this branch opens in an
> editor. You are free to rearrange the lines in any order you want,
> but you have to keep all the lines. When you are done reordering the
> lines, the tool creates a new topic branch and applies the changes
> (probably with cherrypick) to the new topic branch. If there are no
> conflicts, you're done.....
Read the man page for for "git rebase --interactive". I think you
will find that it handles reording and merging (its called squashing)
already.
Splitting patches is harder to do and probably is one of the things
you have to do manually.
- Ted
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Theodore Tso @ 2008-06-28 1:23 UTC (permalink / raw)
To: David Jeske; +Cc: Jakub Narebski, git
On Fri, Jun 27, 2008 at 08:51:41PM -0000, David Jeske wrote:
> -- Jakub Narebski wrote:
> > git rebase --interactive?
> > Any patch management interface (StGIT, Guilt)?
>
> Yes, as I said, that set of operations can be performed with git today.
>
> What git can't do, is let me "supercede" the old DAG-subset, so
> people I shared them with can get my new changes without hurting
> their world. Currently git seems to rely on the idea that "if you
> accept changes into your tree that will be later rebased, it's up to
> you to figure it out". I don't see why that is the case
Because it's fundamentally hard and fraught with danger --- especially
since with git-rebase --interactive you actually can *edit* an
intervening patch, so commits that are based off of a rebased branch
have absolutely no guarantee of correctly applying against the rebased
branch.
If they do apply cleanly, you can use git rebase --onto, but the
possibility of merge conflicts are endless.
The general workflow here is that you simply don't share your git
state until it's been refactored and you're positive that it you've
gotten it right. Or if you do share, it you do so in a branch where
you tell people --- don't base work off of this! (i.e., a "pu" branch
like git has.)
As I said earlier, premature sharing is highly over-rated. And having
people develop against an unstable branch is just extra work for them
anyway. So commit frequently, and if you want to backup your local
hard drive, push regularly to your own private git repository located
off-machine. Just don't ask people base any branches off your private
branch until you're ready to publish it in a form after which you
don't do rebase operations. This works quite well for many projects
and many developers.
- Ted
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Miklos Vajna @ 2008-06-28 1:56 UTC (permalink / raw)
To: Theodore Tso; +Cc: David Jeske, Robert Anderson, Git Mailing List
In-Reply-To: <20080628011723.GB15463@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Fri, Jun 27, 2008 at 09:17:24PM -0400, Theodore Tso <tytso@mit.edu> wrote:
> Splitting patches is harder to do and probably is one of the things
> you have to do manually.
Or not that hard:
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/git-rebase.txt;hb=HEAD#l363
:-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Junio C Hamano @ 2008-06-28 2:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7ea320cd49601de0e331777f82528876101fd946.1214581610.git.vmiklos@frugalware.org>
Do you really think these two patches belong to the series, I seriously
have to wonder?
The series uses strbuf_initf() from 7 call sites to save a few lines per
each call site, and for that you have a 140-line patch to strbuf.c (in
aggregate between this one and the "Oops, I need to support this, too" one
after this).
This new code that is not essential to the series need to be carefully
vetted to avoid risks of potentially affecting existing 70+ users of
strbuf_addf(), which used to use (hopefully more trustworthy) vsnprintf()
from the system, but now uses the new and unproven strbuf_vaddf() that
has "Only supports %<these>" disclaimer at the top.
I am not saying the strbuf_vaddf() patch is not worth considering. It
might help platforms without a working vsnprintf(). But its merit needs
to be defended separately, and I do not want "merge in C" series to be
taken hostage by it.
Other than that, I did not see anything obviously wrong in the diff
between the previous round and this series.
Thanks.
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Junio C Hamano @ 2008-06-28 2:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Avery Pennarun, Stephen R. van den Berg, Git Mailing List
In-Reply-To: <m3lk0qiy2i.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, from time to time there on this mailing list is idea
> to add entries for directories in the index. This could help situation
> like yours, tracking emty directories, faster operations when some trees
> are unchanged, subtree <-> subproject changes.
Tracking empty directories might be helped by having an explicit entry in
the index (even though it may not be the only possible implementation). I
however suspect you are overvaluing it for "some trees are unchanged"
case:
$ mkdir -p a/b
$ stat a | grep Modify
Modify: 2008-06-27 11:38:13.000000000 -0700
$ >a/b/c
$ stat a | grep Modify
Modify: 2008-06-27 11:38:13.000000000 -0700
$ >a/d
$ stat a | grep Modify
Modify: 2008-06-27 11:38:32.000000000 -0700
You have to descend into the leaf level anyway and directory mtime does
not allow you to check that much.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Dmitry Potapov @ 2008-06-28 2:14 UTC (permalink / raw)
To: Robert Anderson; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9af502e50806271014l661dcfc9o4f61ee2b54677bd6@mail.gmail.com>
On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote:
>
> It is too subtle. That the index state - which becomes the next
> committed state - is not available for building or testing before
> committing is a deep flaw.
And why is that? It is like saying that any editor that does not allow
you to compile the file without saving it first has a deep flaw.
In Git, commits are not the same as in CVS. You can commit any changes
and amend them any time later before you publish your changes. So, what
you normally do is to commit your changes and then run test on them.
The advantage of this approach is that you can continue to your normal
work while test are running, besides the tests are running in clear and
control environment, not in the developer working director where always
there is some garbage.
> > Now, this is not necessarily what everybody wants, which is why many
> > people are fine with the index.
>
> But it is something they should want, and should have, if they care
> about the quality of their commits.
Those who care about quality should have a review process, and the
review process works best when all changes are slit in a small logical
steps. How do you propose to that without committing changes first?
> Especially in the common case of
> a project with development lines which have some sort of policy about
> build/test requirements. How do you ensure your commits obey that
> policy if you cannot verify it?
You can verify it, but you do that _after_ you committed changes but
before you publish them. BTW, policy may include that it should be
compiled and tested on a few platforms, so you cannot do that in
your working directory anyway.
I think the source of your confusion is that you consider git commit
as cvs commit, while git commit in some sense may be closer to saving
files, while a better analogue for cvs commit will be git push to a
public repository.
Dmitry
^ permalink raw reply
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Miklos Vajna @ 2008-06-28 2:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7vk5gal3my.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
On Fri, Jun 27, 2008 at 07:00:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Do you really think these two patches belong to the series, I seriously
> have to wonder?
Well, no. I was suggested to include it there, but you have reason about
it should be a different series.
> Other than that, I did not see anything obviously wrong in the diff
> between the previous round and this series.
OK, I'll send the main patch without the strbuf_initf() calls, and then
you can just fetch from git/vmiklos.git or drop Dscho's two patches from
my topic branch.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 13/13] Build in merge
From: Miklos Vajna @ 2008-06-28 2:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <20080628023355.GH2058@genesis.frugalware.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sat, Jun 28, 2008 at 04:33:55AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> OK, I'll send the main patch without the strbuf_initf() calls
Here it is.
Makefile | 2 +-
builtin-merge.c | 1148 +++++++++++++++++++++++++
builtin.h | 1 +
git-merge.sh => contrib/examples/git-merge.sh | 0
git.c | 1 +
5 files changed, 1151 insertions(+), 1 deletions(-)
create mode 100644 builtin-merge.c
rename git-merge.sh => contrib/examples/git-merge.sh (100%)
diff --git a/Makefile b/Makefile
index 3584b8c..dab29b0 100644
--- a/Makefile
+++ b/Makefile
@@ -240,7 +240,6 @@ SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
-SCRIPT_SH += git-merge.sh
SCRIPT_SH += git-merge-stupid.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-parse-remote.sh
@@ -514,6 +513,7 @@ BUILTIN_OBJS += builtin-ls-remote.o
BUILTIN_OBJS += builtin-ls-tree.o
BUILTIN_OBJS += builtin-mailinfo.o
BUILTIN_OBJS += builtin-mailsplit.o
+BUILTIN_OBJS += builtin-merge.o
BUILTIN_OBJS += builtin-merge-base.o
BUILTIN_OBJS += builtin-merge-file.o
BUILTIN_OBJS += builtin-merge-ours.o
diff --git a/builtin-merge.c b/builtin-merge.c
new file mode 100644
index 0000000..39bfbd1
--- /dev/null
+++ b/builtin-merge.c
@@ -0,0 +1,1148 @@
+/*
+ * Builtin "git merge"
+ *
+ * Copyright (c) 2008 Miklos Vajna <vmiklos@frugalware.org>
+ *
+ * Based on git-merge.sh by Junio C Hamano.
+ */
+
+#include "cache.h"
+#include "parse-options.h"
+#include "builtin.h"
+#include "run-command.h"
+#include "path-list.h"
+#include "diff.h"
+#include "refs.h"
+#include "commit.h"
+#include "diffcore.h"
+#include "revision.h"
+#include "unpack-trees.h"
+#include "cache-tree.h"
+#include "dir.h"
+#include "utf8.h"
+#include "log-tree.h"
+#include "color.h"
+
+enum strategy {
+ DEFAULT_TWOHEAD = 1,
+ DEFAULT_OCTOPUS = 2,
+ NO_FAST_FORWARD = 4,
+ NO_TRIVIAL = 8
+};
+
+static const char * const builtin_merge_usage[] = {
+ "git-merge [options] <remote>...",
+ "git-merge [options] <msg> HEAD <remote>",
+ NULL
+};
+
+static int show_diffstat = 1, option_log, squash;
+static int option_commit = 1, allow_fast_forward = 1;
+static int allow_trivial = 1, have_message;
+static struct strbuf merge_msg;
+static struct commit_list *remoteheads;
+static unsigned char head[20];
+static struct path_list use_strategies;
+static const char *branch;
+
+static struct path_list_item strategy_items[] = {
+ { "recur", (void *)NO_TRIVIAL },
+ { "recursive", (void *)(DEFAULT_TWOHEAD | NO_TRIVIAL) },
+ { "octopus", (void *)DEFAULT_OCTOPUS },
+ { "resolve", (void *)0 },
+ { "stupid", (void *)0 },
+ { "ours", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
+ { "subtree", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
+};
+static struct path_list strategies = { strategy_items,
+ ARRAY_SIZE(strategy_items), 0, 0 };
+
+static const char *pull_twohead, *pull_octopus;
+
+static int option_parse_message(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct strbuf *buf = opt->value;
+
+ if (unset)
+ strbuf_setlen(buf, 0);
+ else {
+ strbuf_addf(buf, "%s\n\n", arg);
+ have_message = 1;
+ }
+ return 0;
+}
+
+static struct path_list_item *unsorted_path_list_lookup(const char *path,
+ struct path_list *list)
+{
+ int i;
+
+ if (!path)
+ return NULL;
+
+ for (i = 0; i < list->nr; i++)
+ if (!strcmp(path, list->items[i].path))
+ return &list->items[i];
+ return NULL;
+}
+
+static inline void path_list_append_strategy(
+ struct path_list_item *item)
+{
+ path_list_append(item->path, &use_strategies)->util = item->util;
+}
+
+static int option_parse_strategy(const struct option *opt,
+ const char *arg, int unset)
+{
+ int i;
+ struct path_list_item *item =
+ unsorted_path_list_lookup(arg, &strategies);
+
+ if (unset)
+ return 0;
+
+ if (item)
+ path_list_append_strategy(item);
+ else {
+ struct strbuf err;
+ strbuf_init(&err, 0);
+ for (i = 0; i < strategies.nr; i++)
+ strbuf_addf(&err, " %s", strategies.items[i].path);
+ fprintf(stderr, "Could not find merge strategy '%s'.\n", arg);
+ fprintf(stderr, "Available strategies are:%s.\n", err.buf);
+ exit(1);
+ }
+ return 0;
+}
+
+static int option_parse_n(const struct option *opt,
+ const char *arg, int unset)
+{
+ show_diffstat = unset;
+ return 0;
+}
+
+static struct option builtin_merge_options[] = {
+ { OPTION_CALLBACK, 'n', NULL, NULL, NULL,
+ "do not show a diffstat at the end of the merge",
+ PARSE_OPT_NOARG, option_parse_n },
+ OPT_BOOLEAN(0, "stat", &show_diffstat,
+ "show a diffstat at the end of the merge"),
+ OPT_BOOLEAN(0, "summary", &show_diffstat, "(synonym to --stat)"),
+ OPT_BOOLEAN(0, "log", &option_log,
+ "add list of one-line log to merge commit message"),
+ OPT_BOOLEAN(0, "squash", &squash,
+ "create a single commit instead of doing a merge"),
+ OPT_BOOLEAN(0, "commit", &option_commit,
+ "perform a commit if the merge succeeds (default)"),
+ OPT_BOOLEAN(0, "ff", &allow_fast_forward,
+ "allow fast forward (default)"),
+ OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
+ "merge strategy to use", option_parse_strategy),
+ OPT_CALLBACK('m', "message", &merge_msg, "message",
+ "message to be used for the merge commit (if any)",
+ option_parse_message),
+ OPT_END()
+};
+
+/* Cleans up metadata that is uninteresting after a succeeded merge. */
+static void dropsave(void)
+{
+ unlink(git_path("MERGE_HEAD"));
+ unlink(git_path("MERGE_MSG"));
+ unlink(git_path("MERGE_STASH"));
+}
+
+static void save_state(void)
+{
+ int fd;
+ struct child_process stash;
+ const char *argv[] = {"stash", "create", NULL};
+
+ fd = open(git_path("MERGE_STASH"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could not write to %s", git_path("MERGE_STASH"));
+ memset(&stash, 0, sizeof(stash));
+ stash.argv = argv;
+ stash.out = fd;
+ stash.git_cmd = 1;
+ run_command(&stash);
+}
+
+static void reset_hard(unsigned const char *sha1, int verbose)
+{
+ struct tree *tree;
+ struct unpack_trees_options opts;
+ struct tree_desc t;
+
+ memset(&opts, 0, sizeof(opts));
+ opts.head_idx = -1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.update = 1;
+ opts.reset = 1;
+ if (verbose)
+ opts.verbose_update = 1;
+
+ tree = parse_tree_indirect(sha1);
+ if (!tree)
+ die("failed to unpack %s tree object", sha1_to_hex(sha1));
+ parse_tree(tree);
+ init_tree_desc(&t, tree->buffer, tree->size);
+ if (unpack_trees(1, &t, &opts))
+ exit(128); /* We've already reported the error, finish dying */
+}
+
+static void restore_state(void)
+{
+ struct strbuf sb;
+ const char *args[] = { "stash", "apply", NULL, NULL };
+
+ if (access(git_path("MERGE_STASH"), R_OK) < 0)
+ return;
+
+ reset_hard(head, 1);
+
+ strbuf_init(&sb, 0);
+ if (strbuf_read_file(&sb, git_path("MERGE_STASH"), 0) < 0)
+ die("could not read MERGE_STASH: %s", strerror(errno));
+ args[2] = sb.buf;
+
+ /*
+ * It is OK to ignore error here, for example when there was
+ * nothing to restore.
+ */
+ run_command_v_opt(args, RUN_GIT_CMD);
+
+ strbuf_release(&sb);
+ refresh_cache(REFRESH_QUIET);
+}
+
+/* This is called when no merge was necessary. */
+static void finish_up_to_date(const char *msg)
+{
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ dropsave();
+}
+
+static void squash_message(void)
+{
+ struct rev_info rev;
+ struct commit *commit;
+ struct strbuf out;
+ struct commit_list *j;
+ int fd;
+
+ printf("Squash commit -- not updating HEAD\n");
+ fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could not write to %s", git_path("SQUASH_MSG"));
+
+ init_revisions(&rev, NULL);
+ rev.ignore_merges = 1;
+ rev.commit_format = CMIT_FMT_MEDIUM;
+
+ commit = lookup_commit(head);
+ commit->object.flags |= UNINTERESTING;
+ add_pending_object(&rev, &commit->object, NULL);
+
+ for (j = remoteheads; j; j = j->next)
+ add_pending_object(&rev, &j->item->object, NULL);
+
+ setup_revisions(0, NULL, &rev, NULL);
+ if (prepare_revision_walk(&rev))
+ die("revision walk setup failed");
+
+ strbuf_init(&out, 0);
+ strbuf_addstr(&out, "Squashed commit of the following:\n");
+ while ((commit = get_revision(&rev)) != NULL) {
+ strbuf_addch(&out, '\n');
+ strbuf_addf(&out, "commit %s\n",
+ sha1_to_hex(commit->object.sha1));
+ pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
+ NULL, NULL, rev.date_mode, 0);
+ }
+ write(fd, out.buf, out.len);
+ close(fd);
+ strbuf_release(&out);
+}
+
+static int run_hook(const char *name)
+{
+ struct child_process hook;
+ const char *argv[3], *env[2];
+ char index[PATH_MAX];
+
+ argv[0] = git_path("hooks/%s", name);
+ if (access(argv[0], X_OK) < 0)
+ return 0;
+
+ snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", get_index_file());
+ env[0] = index;
+ env[1] = NULL;
+
+ if (squash)
+ argv[1] = "1";
+ else
+ argv[1] = "0";
+ argv[2] = NULL;
+
+ memset(&hook, 0, sizeof(hook));
+ hook.argv = argv;
+ hook.no_stdin = 1;
+ hook.stdout_to_stderr = 1;
+ hook.env = env;
+
+ return run_command(&hook);
+}
+
+static void finish(const unsigned char *new_head, const char *msg)
+{
+ struct strbuf reflog_message;
+
+ strbuf_init(&reflog_message, 0);
+ if (!msg)
+ strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
+ else {
+ printf("%s\n", msg);
+ strbuf_addf(&reflog_message, "%s: %s",
+ getenv("GIT_REFLOG_ACTION"), msg);
+ }
+ if (squash) {
+ squash_message();
+ } else {
+ if (!merge_msg.len)
+ printf("No merge message -- not updating HEAD\n");
+ else {
+ const char *argv_gc_auto[] = { "gc", "--auto", NULL };
+ update_ref(reflog_message.buf, "HEAD",
+ new_head, head, 0,
+ DIE_ON_ERR);
+ /*
+ * We ignore errors in 'gc --auto', since the
+ * user should see them.
+ */
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ }
+ }
+ if (new_head && show_diffstat) {
+ struct diff_options opts;
+ diff_setup(&opts);
+ opts.output_format |=
+ DIFF_FORMAT_SUMMARY | DIFF_FORMAT_DIFFSTAT;
+ opts.detect_rename = DIFF_DETECT_RENAME;
+ if (diff_use_color_default > 0)
+ DIFF_OPT_SET(&opts, COLOR_DIFF);
+ diff_tree_sha1(head, new_head, "", &opts);
+ diffcore_std(&opts);
+ diff_flush(&opts);
+ }
+
+ /* Run a post-merge hook */
+ run_hook("post-merge");
+
+ strbuf_release(&reflog_message);
+}
+
+/* Get the name for the merge commit's message. */
+static void merge_name(const char *remote, struct strbuf *msg)
+{
+ struct object *remote_head;
+ unsigned char branch_head[20], buf_sha[20];
+ struct strbuf buf;
+ char *ptr;
+ int len = 0;
+
+ memset(branch_head, 0, sizeof(branch_head));
+ remote_head = peel_to_type(remote, 0, NULL, OBJ_COMMIT);
+ if (!remote_head)
+ return;
+
+ strbuf_init(&buf, 0);
+ strbuf_addstr(&buf, "refs/heads/");
+ strbuf_addstr(&buf, remote);
+ get_sha1(buf.buf, branch_head);
+
+ if (!hashcmp(remote_head->sha1, branch_head)) {
+ strbuf_addf(msg, "%s\t\tbranch '%s' of .\n",
+ sha1_to_hex(branch_head), remote);
+ return;
+ }
+ /* See if remote matches <name>~<number>, or <name>^ */
+ ptr = strrchr(remote, '^');
+ if (ptr && ptr[1] == '\0')
+ len = ptr-remote;
+ else {
+ ptr = strrchr(remote, '~');
+ if (ptr && ptr[1] != '0' && isdigit(ptr[1])) {
+ len = ptr-remote;
+ ptr++;
+ for (ptr++; *ptr; ptr++)
+ if (!isdigit(*ptr)) {
+ len = 0;
+ break;
+ }
+ }
+ }
+ if (len) {
+ struct strbuf truname = STRBUF_INIT;
+ strbuf_addstr(&truname, remote);
+ strbuf_setlen(&truname, len);
+ if (!get_sha1(truname.buf, buf_sha)) {
+ strbuf_addf(msg,
+ "%s\t\tbranch '%s' (early part) of .\n",
+ sha1_to_hex(remote_head->sha1), truname.buf);
+ return;
+ }
+ }
+
+ if (!strcmp(remote, "FETCH_HEAD") &&
+ !access(git_path("FETCH_HEAD"), R_OK)) {
+ FILE *fp;
+ struct strbuf line;
+ char *ptr;
+
+ strbuf_init(&line, 0);
+ fp = fopen(git_path("FETCH_HEAD"), "r");
+ if (!fp)
+ die("could not open %s for reading: %s",
+ git_path("FETCH_HEAD"), strerror(errno));
+ strbuf_getline(&line, fp, '\n');
+ fclose(fp);
+ ptr = strstr(line.buf, "\tnot-for-merge\t");
+ if (ptr)
+ strbuf_remove(&line, ptr-line.buf+1, 13);
+ strbuf_addbuf(msg, &line);
+ strbuf_release(&line);
+ return;
+ }
+ strbuf_addf(msg, "%s\t\tcommit '%s'\n",
+ sha1_to_hex(remote_head->sha1), remote);
+}
+
+int git_merge_config(const char *k, const char *v, void *cb)
+{
+ if (branch && !prefixcmp(k, "branch.") &&
+ !prefixcmp(k + 7, branch) &&
+ !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
+ const char **argv;
+ int argc;
+ char *buf;
+
+ buf = xstrdup(v);
+ argc = split_cmdline(buf, &argv);
+ argv = xrealloc(argv, sizeof(*argv) * (argc + 2));
+ memmove(argv + 1, argv, sizeof(*argv) * (argc + 1));
+ argc++;
+ parse_options(argc, argv, builtin_merge_options,
+ builtin_merge_usage, 0);
+ free(buf);
+ }
+
+ if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
+ show_diffstat = git_config_bool(k, v);
+ else if (!strcmp(k, "pull.twohead"))
+ return git_config_string(&pull_twohead, k, v);
+ else if (!strcmp(k, "pull.octopus"))
+ return git_config_string(&pull_octopus, k, v);
+ return 0;
+}
+
+static int read_tree_trivial(unsigned char *common, unsigned char *head,
+ unsigned char *one)
+{
+ int i, nr_trees = 0;
+ struct tree *trees[MAX_UNPACK_TREES];
+ struct tree_desc t[MAX_UNPACK_TREES];
+ struct unpack_trees_options opts;
+
+ memset(&opts, 0, sizeof(opts));
+ opts.head_idx = -1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.update = 1;
+ opts.verbose_update = 1;
+ opts.trivial_merges_only = 1;
+ opts.merge = 1;
+ trees[nr_trees] = parse_tree_indirect(common);
+ if (!trees[nr_trees++])
+ return -1;
+ trees[nr_trees] = parse_tree_indirect(head);
+ if (!trees[nr_trees++])
+ return -1;
+ trees[nr_trees] = parse_tree_indirect(one);
+ if (!trees[nr_trees++])
+ return -1;
+ opts.fn = threeway_merge;
+ cache_tree_free(&active_cache_tree);
+ opts.head_idx = 2;
+ for (i = 0; i < nr_trees; i++) {
+ parse_tree(trees[i]);
+ init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
+ }
+ if (unpack_trees(nr_trees, t, &opts))
+ return -1;
+ return 0;
+}
+
+static int commit_tree_trivial(const char *msg, unsigned const char *tree,
+ struct commit_list *parents, unsigned char *ret)
+{
+ struct commit_list *i;
+ struct strbuf buf;
+ int encoding_is_utf8;
+
+ /* Not having i18n.commitencoding is the same as having utf-8 */
+ encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
+
+ strbuf_init(&buf, 8192); /* should avoid reallocs for the headers */
+ strbuf_addf(&buf, "tree %s\n", sha1_to_hex(tree));
+
+ for (i = parents; i; i = i->next)
+ strbuf_addf(&buf, "parent %s\n",
+ sha1_to_hex(i->item->object.sha1));
+
+ /* Person/date information */
+ strbuf_addf(&buf, "author %s\n",
+ git_author_info(IDENT_ERROR_ON_NO_NAME));
+ strbuf_addf(&buf, "committer %s\n",
+ git_committer_info(IDENT_ERROR_ON_NO_NAME));
+ if (!encoding_is_utf8)
+ strbuf_addf(&buf, "encoding %s\n", git_commit_encoding);
+ strbuf_addch(&buf, '\n');
+
+ /* And add the comment */
+ strbuf_addstr(&buf, msg);
+
+ write_sha1_file(buf.buf, buf.len, commit_type, ret);
+ strbuf_release(&buf);
+ return *ret;
+}
+
+static void write_tree_trivial(unsigned char *sha1)
+{
+ if (write_cache_as_tree(sha1, 0, NULL))
+ die("git write-tree failed to write a tree");
+}
+
+static int try_merge_strategy(char *strategy, struct commit_list *common,
+ struct strbuf *head_arg)
+{
+ const char **args;
+ int i = 0, ret;
+ struct commit_list *j;
+ struct strbuf buf;
+
+ args = xmalloc((4 + commit_list_count(common) +
+ commit_list_count(remoteheads)) * sizeof(char *));
+ strbuf_init(&buf, 0);
+ strbuf_addf(&buf, "merge-%s", strategy);
+ args[i++] = buf.buf;
+ for (j = common; j; j = j->next)
+ args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
+ args[i++] = "--";
+ args[i++] = head_arg->buf;
+ for (j = remoteheads; j; j = j->next)
+ args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
+ args[i] = NULL;
+ ret = run_command_v_opt(args, RUN_GIT_CMD);
+ strbuf_release(&buf);
+ i = 1;
+ for (j = common; j; j = j->next)
+ free((void *)args[i++]);
+ i += 2;
+ for (j = remoteheads; j; j = j->next)
+ free((void *)args[i++]);
+ free(args);
+ return -ret;
+}
+
+static void count_diff_files(struct diff_queue_struct *q,
+ struct diff_options *opt, void *data)
+{
+ int *count = data;
+
+ (*count) += q->nr;
+}
+
+static int count_unmerged_entries(void)
+{
+ const struct index_state *state = &the_index;
+ int i, ret = 0;
+
+ for (i = 0; i < state->cache_nr; i++)
+ if (ce_stage(state->cache[i]))
+ ret++;
+
+ return ret;
+}
+
+static int merge_one_remote(unsigned char *head, unsigned char *remote)
+{
+ struct tree *trees[MAX_UNPACK_TREES];
+ struct unpack_trees_options opts;
+ struct tree_desc t[MAX_UNPACK_TREES];
+ int i, fd, nr_trees = 0;
+ struct dir_struct dir;
+ struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
+
+ if (read_cache_unmerged())
+ die("you need to resolve your current index first");
+
+ fd = hold_locked_index(lock_file, 1);
+
+ memset(&trees, 0, sizeof(trees));
+ memset(&opts, 0, sizeof(opts));
+ memset(&t, 0, sizeof(t));
+ dir.show_ignored = 1;
+ dir.exclude_per_dir = ".gitignore";
+ opts.dir = &dir;
+
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.update = 1;
+ opts.verbose_update = 1;
+ opts.merge = 1;
+ opts.fn = twoway_merge;
+
+ trees[nr_trees] = parse_tree_indirect(head);
+ if (!trees[nr_trees++])
+ return -1;
+ trees[nr_trees] = parse_tree_indirect(remote);
+ if (!trees[nr_trees++])
+ return -1;
+ for (i = 0; i < nr_trees; i++) {
+ parse_tree(trees[i]);
+ init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
+ }
+ if (unpack_trees(nr_trees, t, &opts))
+ return -1;
+ if (write_cache(fd, active_cache, active_nr) ||
+ commit_locked_index(lock_file))
+ die("unable to write new index file");
+ return 0;
+}
+
+static void split_merge_strategies(const char *string, struct path_list *list)
+{
+ char *p, *q, *buf;
+
+ if (!string)
+ return;
+
+ list->strdup_paths = 1;
+ buf = xstrdup(string);
+ q = buf;
+ for (;;) {
+ p = strchr(q, ' ');
+ if (!p) {
+ path_list_append(q, list);
+ free(buf);
+ return;
+ } else {
+ *p = '\0';
+ path_list_append(q, list);
+ q = ++p;
+ }
+ }
+}
+
+static void add_strategies(const char *string, enum strategy strategy)
+{
+ struct path_list list;
+ int i;
+
+ memset(&list, 0, sizeof(list));
+ split_merge_strategies(string, &list);
+ if (list.nr) {
+ for (i = 0; i < list.nr; i++) {
+ struct path_list_item *item;
+
+ item = unsorted_path_list_lookup(list.items[i].path,
+ &strategies);
+ if (item)
+ path_list_append_strategy(item);
+ }
+ return;
+ }
+ for (i = 0; i < strategies.nr; i++)
+ if ((enum strategy)strategies.items[i].util & strategy)
+ path_list_append_strategy(&strategies.items[i]);
+}
+
+int cmd_merge(int argc, const char **argv, const char *prefix)
+{
+ unsigned char sha1[20], result_tree[20];
+ struct object *second_token = NULL;
+ struct strbuf buf, head_arg;
+ int flag, head_invalid, i, single_strategy;
+ int best_cnt = -1, merge_was_ok = 0, automerge_was_ok = 0;
+ struct commit_list *common = NULL;
+ struct path_list_item *best_strategy = NULL, *wt_strategy = NULL;
+ struct commit_list **remotes = &remoteheads;
+
+ setup_work_tree();
+ if (unmerged_cache())
+ die("You are in the middle of a conflicted merge.");
+
+ /*
+ * Check if we are _not_ on a detached HEAD, i.e. if there is a
+ * current branch.
+ */
+ branch = resolve_ref("HEAD", sha1, 0, &flag);
+ if (branch && flag & REF_ISSYMREF) {
+ const char *ptr = skip_prefix(branch, "refs/heads/");
+ if (ptr)
+ branch = ptr;
+ }
+
+ git_config(git_merge_config, NULL);
+
+ /* for color.diff and diff.color */
+ git_config(git_diff_ui_config, NULL);
+
+ /* for color.ui */
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
+ argc = parse_options(argc, argv, builtin_merge_options,
+ builtin_merge_usage, 0);
+
+ if (squash) {
+ if (!allow_fast_forward)
+ die("You cannot combine --squash with --no-ff.");
+ option_commit = 0;
+ }
+
+ if (!argc)
+ usage_with_options(builtin_merge_usage,
+ builtin_merge_options);
+
+ /*
+ * 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.
+ */
+ strbuf_init(&buf, 0);
+ strbuf_init(&head_arg, 0);
+ if (argc > 1)
+ second_token = peel_to_type(argv[1], 0, NULL, OBJ_COMMIT);
+ head_invalid = get_sha1("HEAD", head);
+
+ if (!have_message && second_token &&
+ !hashcmp(second_token->sha1, head)) {
+ strbuf_addstr(&merge_msg, argv[0]);
+ strbuf_addstr(&head_arg, argv[1]);
+ argv += 2;
+ argc -= 2;
+ } else if (head_invalid) {
+ struct object *remote_head;
+ /*
+ * If the merged head is a valid one there is no reason
+ * to forbid "git merge" into a branch yet to be born.
+ * We do the same for "git pull".
+ */
+ if (argc != 1)
+ die("Can merge only exactly one commit into "
+ "empty head");
+ remote_head = peel_to_type(argv[0], 0, NULL, OBJ_COMMIT);
+ if (!remote_head)
+ die("%s - not something we can merge", argv[0]);
+ update_ref("initial pull", "HEAD", remote_head->sha1, NULL, 0,
+ DIE_ON_ERR);
+ reset_hard(remote_head->sha1, 0);
+ return 0;
+ } else {
+ /* We are invoked directly as the first-class UI. */
+ strbuf_addstr(&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.
+ */
+ struct strbuf msg;
+
+ strbuf_init(&msg, 0);
+ for (i = 0; i < argc; i++)
+ merge_name(argv[i], &msg);
+ fmt_merge_msg(option_log, &msg, &merge_msg);
+ if (merge_msg.len)
+ strbuf_setlen(&merge_msg, merge_msg.len-1);
+ }
+
+ if (head_invalid || !argc)
+ usage_with_options(builtin_merge_usage,
+ builtin_merge_options);
+
+ strbuf_addstr(&buf, "merge");
+ for (i = 0; i < argc; i++)
+ strbuf_addf(&buf, " %s", argv[i]);
+ setenv("GIT_REFLOG_ACTION", buf.buf, 0);
+ strbuf_reset(&buf);
+
+ for (i = 0; i < argc; i++) {
+ struct object *o;
+
+ o = peel_to_type(argv[i], 0, NULL, OBJ_COMMIT);
+ if (!o)
+ die("%s - not something we can merge", argv[i]);
+ remotes = &commit_list_insert(lookup_commit(o->sha1),
+ remotes)->next;
+
+ strbuf_addf(&buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
+ setenv(buf.buf, argv[i], 1);
+ strbuf_reset(&buf);
+ }
+
+ if (!use_strategies.nr) {
+ if (!remoteheads->next)
+ add_strategies(pull_twohead, DEFAULT_TWOHEAD);
+ else
+ add_strategies(pull_octopus, DEFAULT_OCTOPUS);
+ }
+
+ for (i = 0; i < use_strategies.nr; i++) {
+ if ((unsigned int)use_strategies.items[i].util &
+ NO_FAST_FORWARD)
+ allow_fast_forward = 0;
+ if ((unsigned int)use_strategies.items[i].util & NO_TRIVIAL)
+ allow_trivial = 0;
+ }
+
+ if (!remoteheads->next)
+ common = get_merge_bases(lookup_commit(head),
+ remoteheads->item, 1);
+ else {
+ struct commit_list *list = remoteheads;
+ commit_list_insert(lookup_commit(head), &list);
+ common = get_octopus_merge_bases(list);
+ free(list);
+ }
+
+ update_ref("updating ORIG_HEAD", "ORIG_HEAD", head, NULL, 0,
+ DIE_ON_ERR);
+
+ if (!common)
+ ; /* No common ancestors found. We need a real merge. */
+ else if (!remoteheads->next &&
+ !hashcmp(common->item->object.sha1,
+ remoteheads->item->object.sha1)) {
+ /*
+ * If head can reach all the remote heads then we are up
+ * to date.
+ */
+ finish_up_to_date("Already up-to-date.");
+ return 0;
+ } else if (allow_fast_forward && !remoteheads->next &&
+ !hashcmp(common->item->object.sha1, head)) {
+ /* Again the most common case of merging one remote. */
+ struct strbuf msg;
+ struct object *o;
+ char hex[41];
+
+ strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
+
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
+ refresh_cache(REFRESH_QUIET);
+ strbuf_init(&msg, 0);
+ strbuf_addstr(&msg, "Fast forward");
+ if (have_message)
+ strbuf_addstr(&msg,
+ " (no commit created; -m option ignored)");
+ o = peel_to_type(sha1_to_hex(remoteheads->item->object.sha1),
+ 0, NULL, OBJ_COMMIT);
+ if (!o)
+ return 0;
+
+ if (merge_one_remote(head, remoteheads->item->object.sha1))
+ return 0;
+
+ finish(o->sha1, msg.buf);
+ dropsave();
+ return 0;
+ } else if (!remoteheads->next && common->next)
+ ;
+ /*
+ * We are not doing octopus and not fast forward. Need
+ * a real merge.
+ */
+ else if (!remoteheads->next && option_commit) {
+ /*
+ * We are not doing octopus, not fast forward, and have
+ * only one common.
+ */
+ refresh_cache(REFRESH_QUIET);
+ if (allow_trivial) {
+ /* See if it is really trivial. */
+ git_committer_info(IDENT_ERROR_ON_NO_NAME);
+ printf("Trying really trivial in-index merge...\n");
+ if (!read_tree_trivial(common->item->object.sha1,
+ head, remoteheads->item->object.sha1)) {
+ unsigned char result_tree[20],
+ result_commit[20];
+ struct commit_list parent;
+
+ write_tree_trivial(result_tree);
+ printf("Wonderful.\n");
+ parent.item = remoteheads->item;
+ parent.next = NULL;
+ commit_tree_trivial(merge_msg.buf,
+ result_tree, &parent,
+ result_commit);
+ finish(result_commit, "In-index merge");
+ dropsave();
+ return 0;
+ }
+ printf("Nope.\n");
+ }
+ } else {
+ /*
+ * An octopus. If we can reach all the remote we are up
+ * to date.
+ */
+ int up_to_date = 1;
+ struct commit_list *j;
+
+ for (j = remoteheads; j; j = j->next) {
+ struct commit_list *common_one;
+
+ /*
+ * Here we *have* to calculate the individual
+ * merge_bases again, otherwise "git merge HEAD^
+ * HEAD^^" would be missed.
+ */
+ common_one = get_merge_bases(lookup_commit(head),
+ j->item, 1);
+ if (hashcmp(common_one->item->object.sha1,
+ j->item->object.sha1)) {
+ up_to_date = 0;
+ break;
+ }
+ }
+ if (up_to_date) {
+ finish_up_to_date("Already up-to-date. Yeeah!");
+ return 0;
+ }
+ }
+
+ /* We are going to make a new commit. */
+ git_committer_info(IDENT_ERROR_ON_NO_NAME);
+
+ /*
+ * At this point, we need a real merge. No matter what strategy
+ * we use, it would operate on the index, possibly affecting the
+ * working tree, and when resolved cleanly, have the desired
+ * tree in the index -- this means that the index must be in
+ * sync with the head commit. The strategies are responsible
+ * to ensure this.
+ */
+ if (use_strategies.nr != 1) {
+ /*
+ * Stash away the local changes so that we can try more
+ * than one.
+ */
+ save_state();
+ single_strategy = 0;
+ } else {
+ unlink(git_path("MERGE_STASH"));
+ single_strategy = 1;
+ }
+
+ for (i = 0; i < use_strategies.nr; i++) {
+ int ret;
+ if (i) {
+ printf("Rewinding the tree to pristine...\n");
+ restore_state();
+ }
+ if (!single_strategy)
+ printf("Trying merge strategy %s...\n",
+ use_strategies.items[i].path);
+ /*
+ * Remember which strategy left the state in the working
+ * tree.
+ */
+ wt_strategy = &use_strategies.items[i];
+
+ ret = try_merge_strategy(use_strategies.items[i].path,
+ common, &head_arg);
+ if (!option_commit && !ret) {
+ merge_was_ok = 1;
+ /*
+ * This is necessary here just to avoid writing
+ * the tree, but later we will *not* exit with
+ * status code 1 because merge_was_ok is set.
+ */
+ ret = 1;
+ }
+
+ if (ret) {
+ /*
+ * The backend exits with 1 when conflicts are
+ * left to be resolved, with 2 when it does not
+ * handle the given merge at all.
+ */
+ if (ret == 1) {
+ int cnt = 0;
+ struct rev_info rev;
+
+ if (read_cache() < 0)
+ die("failed to read the cache");
+
+ /* Check how many files differ. */
+ init_revisions(&rev, "");
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.diffopt.output_format |=
+ DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = count_diff_files;
+ rev.diffopt.format_callback_data = &cnt;
+ run_diff_files(&rev, 0);
+
+ /*
+ * Check how many unmerged entries are
+ * there.
+ */
+ cnt += count_unmerged_entries();
+
+ if (best_cnt <= 0 || cnt <= best_cnt) {
+ best_strategy =
+ &use_strategies.items[i];
+ best_cnt = cnt;
+ }
+ }
+ if (merge_was_ok)
+ break;
+ else
+ continue;
+ }
+
+ /* Automerge succeeded. */
+ write_tree_trivial(result_tree);
+ automerge_was_ok = 1;
+ break;
+ }
+
+ /*
+ * If we have a resulting tree, that means the strategy module
+ * auto resolved the merge cleanly.
+ */
+ if (automerge_was_ok) {
+ struct commit_list *parents = NULL, *j;
+ unsigned char result_commit[20];
+
+ free_commit_list(common);
+ if (allow_fast_forward) {
+ parents = remoteheads;
+ commit_list_insert(lookup_commit(head), &parents);
+ parents = reduce_heads(parents);
+ } else {
+ struct commit_list **pptr = &parents;
+
+ pptr = &commit_list_insert(lookup_commit(head),
+ pptr)->next;
+ for (j = remoteheads; j; j = j->next)
+ pptr = &commit_list_insert(j->item, pptr)->next;
+ }
+ free_commit_list(remoteheads);
+ strbuf_addch(&merge_msg, '\n');
+ commit_tree_trivial(merge_msg.buf, result_tree, parents,
+ result_commit);
+ free_commit_list(parents);
+ strbuf_addf(&buf, "Merge made by %s.", wt_strategy->path);
+ finish(result_commit, buf.buf);
+ strbuf_release(&buf);
+ dropsave();
+ return 0;
+ }
+
+ /*
+ * Pick the result from the best strategy and have the user fix
+ * it up.
+ */
+ if (!best_strategy) {
+ restore_state();
+ if (use_strategies.nr > 1)
+ fprintf(stderr,
+ "No merge strategy handled the merge.\n");
+ else
+ fprintf(stderr, "Merge with strategy %s failed.\n",
+ use_strategies.items[0].path);
+ return 2;
+ } else if (best_strategy == wt_strategy)
+ ; /* We already have its result in the working tree. */
+ else {
+ printf("Rewinding the tree to pristine...\n");
+ restore_state();
+ printf("Using the %s to prepare resolving by hand.\n",
+ best_strategy->path);
+ try_merge_strategy(best_strategy->path, common, &head_arg);
+ }
+
+ if (squash)
+ finish(NULL, NULL);
+ else {
+ int fd;
+ struct commit_list *j;
+
+ for (j = remoteheads; j; j = j->next)
+ strbuf_addf(&buf, "%s\n",
+ sha1_to_hex(j->item->object.sha1));
+ fd = open(git_path("MERGE_HEAD"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could open %s for writing",
+ git_path("MERGE_HEAD"));
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die("Could not write to %s", git_path("MERGE_HEAD"));
+ close(fd);
+ strbuf_addch(&merge_msg, '\n');
+ fd = open(git_path("MERGE_MSG"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could open %s for writing", git_path("MERGE_MSG"));
+ if (write_in_full(fd, merge_msg.buf, merge_msg.len) !=
+ merge_msg.len)
+ die("Could not write to %s", git_path("MERGE_MSG"));
+ close(fd);
+ }
+
+ if (merge_was_ok) {
+ fprintf(stderr, "Automatic merge went well; "
+ "stopped before committing as requested\n");
+ return 0;
+ } else {
+ FILE *fp;
+ int pos;
+ const char *argv_rerere[] = { "rerere", NULL };
+
+ fp = fopen(git_path("MERGE_MSG"), "a");
+ if (!fp)
+ die("Could open %s for writing", git_path("MERGE_MSG"));
+ fprintf(fp, "\nConflicts:\n");
+ for (pos = 0; pos < active_nr; pos++) {
+ struct cache_entry *ce = active_cache[pos];
+
+ if (ce_stage(ce)) {
+ fprintf(fp, "\t%s\n", ce->name);
+ while (pos + 1 < active_nr &&
+ !strcmp(ce->name,
+ active_cache[pos + 1]->name))
+ pos++;
+ }
+ }
+ fclose(fp);
+ run_command_v_opt(argv_rerere, RUN_GIT_CMD);
+ printf("Automatic merge failed; "
+ "fix conflicts and then commit the result.\n");
+ return 1;
+ }
+}
diff --git a/builtin.h b/builtin.h
index 2b01fea..8bf5280 100644
--- a/builtin.h
+++ b/builtin.h
@@ -60,6 +60,7 @@ extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_ls_remote(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
extern int cmd_mailsplit(int argc, const char **argv, const char *prefix);
+extern int cmd_merge(int argc, const char **argv, const char *prefix);
extern int cmd_merge_base(int argc, const char **argv, const char *prefix);
extern int cmd_merge_ours(int argc, const char **argv, const char *prefix);
extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
diff --git a/git-merge.sh b/contrib/examples/git-merge.sh
similarity index 100%
rename from git-merge.sh
rename to contrib/examples/git-merge.sh
diff --git a/git.c b/git.c
index 2fbe96b..770aadd 100644
--- a/git.c
+++ b/git.c
@@ -271,6 +271,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "ls-remote", cmd_ls_remote },
{ "mailinfo", cmd_mailinfo },
{ "mailsplit", cmd_mailsplit },
+ { "merge", cmd_merge, RUN_SETUP | NEED_WORK_TREE },
{ "merge-base", cmd_merge_base, RUN_SETUP },
{ "merge-file", cmd_merge_file },
{ "merge-ours", cmd_merge_ours, RUN_SETUP },
--
1.5.6
^ permalink raw reply related
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 2:57 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <20080628021444.GI5737@dpotapov.dyndns.org>
On Fri, Jun 27, 2008 at 7:14 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote:
>>
>> It is too subtle. That the index state - which becomes the next
>> committed state - is not available for building or testing before
>> committing is a deep flaw.
>
> And why is that? It is like saying that any editor that does not allow
> you to compile the file without saving it first has a deep flaw.
I don't believe it is like that. It would be like that if you
intended for your on-tree disk to have a policy to always compile (for
example). That is not a common use-case.
> In Git, commits are not the same as in CVS.
I have not suggested they were.
> You can commit any changes
> and amend them any time later before you publish your changes.
This is enforcing a two-step process where there only need be one the
vast majority of the time, to require that commit and publish be
separate operations.
> Those who care about quality should have a review process, and the
> review process works best when all changes are slit in a small logical
> steps. How do you propose to that without committing changes first?
I don't understand the question. The entire point of the facility I
am proposing is to facilitate creating small clean changesets. Go
back and read my original proposal, or Junio's statement of more or
less the same idea, to see how it is proposed to do this.
> You can verify it, but you do that _after_ you committed changes but
> before you publish them.
Again, this is requiring two steps when it is otherwise not required,
creating an inefficient workflow that is error prone.
> BTW, policy may include that it should be
> compiled and tested on a few platforms, so you cannot do that in
> your working directory anyway.
Huh? I have done that every day for 15+ years.
> I think the source of your confusion is that you consider git commit
> as cvs commit
No. I have experience with a wide array of source control systems.
CVS fits my mental model the least well. git is pretty close, but it
is not there yet. The current partial commit facility is the biggest
misfire, in my view.
I like that git's philosophy does not include a draconian policy of
not changing history. That's fine, it's practical, and it's useful,
to cover common scenarios in which you'd like to quickly recover from
a mistake. However, I am afraid that these facilities have been
abused and turned into something that they are not well-suited for,
i.e., the use of lines of development as both keepers of history and
of scratch spaces where you scribble around with temporary things, all
the while git having no clue which is intended. That these ideas are
conflated is a mistake. That's my opinion. These activities ought to
occur in separate, logically distinct spaces in which they occur,
because they have different requirements and common use-cases.
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Dmitry Potapov @ 2008-06-28 2:57 UTC (permalink / raw)
To: Robert Anderson; +Cc: Junio C Hamano, David Jeske, Jakub Narebski, git
In-Reply-To: <9af502e50806271708p7979ae65k61b71be90efff2c4@mail.gmail.com>
On Fri, Jun 27, 2008 at 05:08:57PM -0700, Robert Anderson wrote:
>
> In the existing model which is being suggested as a way to get the
> desired workflow, there are two distinct classes of commits: commits
> that are "for real", and commits that are "temporary", that are being
> used as some kind of workspace for orthogonalizing a set of changes,
> which will eventually be replaced by "for real" commits.
Not really. Good commits do not get replaced by anything. They are
just pushed to the public repo after being tested. Those commits
that have not passed the test should be amended and tested again.
> Yet git has
> no metadata to distinguish these two types of commits. When only "for
> real" commits exist, I can push HEAD. When "temporary" commits exist,
> I cannot, or insidious problems will ensue. This metadata concerning
> "for real" or "temporary" commits is only maintained manually in the
> developer's head.
No, you can use a tag for that, which marks the tip of tested commits;
or you can make your test procedure to push commits automatically after
successful testing. There is no reason for Git to have any metadata for
that.
Dmitry
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 3:31 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, David Jeske, Jakub Narebski, git
In-Reply-To: <20080628025704.GJ5737@dpotapov.dyndns.org>
On Fri, Jun 27, 2008 at 7:57 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Fri, Jun 27, 2008 at 05:08:57PM -0700, Robert Anderson wrote:
>>
>> In the existing model which is being suggested as a way to get the
>> desired workflow, there are two distinct classes of commits: commits
>> that are "for real", and commits that are "temporary", that are being
>> used as some kind of workspace for orthogonalizing a set of changes,
>> which will eventually be replaced by "for real" commits.
>
> Not really. Good commits do not get replaced by anything. They are
> just pushed to the public repo after being tested. Those commits
> that have not passed the test should be amended and tested again.
>
>> Yet git has
>> no metadata to distinguish these two types of commits. When only "for
>> real" commits exist, I can push HEAD. When "temporary" commits exist,
>> I cannot, or insidious problems will ensue. This metadata concerning
>> "for real" or "temporary" commits is only maintained manually in the
>> developer's head.
>
> No, you can use a tag for that, which marks the tip of tested commits;
> or you can make your test procedure to push commits automatically after
> successful testing. There is no reason for Git to have any metadata for
> that.
>
> Dmitry
There is a disconnect here. Rather than argue somewhat abstractly, I
will try to construct some concrete examples which illustrate the
essential problems with the current model and some proposed solutions
to improve it.
Bob
^ 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