* Re: Considering teaching plumbing to users harmful
From: Andreas Ericsson @ 2008-07-18 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807161804400.8950@racer>
Johannes Schindelin wrote:
> Hi,
>
> there have been a number of occasions where I came across people trying to
> be helpful and teaching Git newbies a few tricks.
>
> However, in quite a number of cases, which seem to surge over the last
> weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list
> etc.
>
> Their rationale is invariably "but I found it useful", and they seem to be
> unable to recognize the puzzlement in the faces of the people they are
> trying to help.
>
> Instead they insist that they did nothing wrong.
>
> I had the pleasure of introducing Git to a few users in the last months
> and in my opinion, restricting myself to teaching them these commands
> first helped tremendously:
>
> - clone, pull, status, add, commit, push, log
>
> All of these were presented without options, to keep things simple.
>
> In particular, I refrained from giving them the "-a" option to commit.
> That seemed to help incredibly with their embracing the index as a natural
> concept (which it is).
>
> Often I presented the "pull" and "push" commands _only_ with "origin
> master" ("origin is where the repository came from, and master is the
> branch; you will want to use other parameters here after you used Git for
> a while").
>
> _After_ they grew comfortable with Git, I taught them a few options here
> and there, not hiding, but also not promoting the full range of options.
>
> So the next tricks were
>
> - log -p, rm, diff, diff --cached, show
>
> The last one is "show", and with that command, I taught the
> "<commit>:" and "<commit>:<file>" syntax, too (which some Git old-timers
> did not know about ;-)
>
Thanks for the excellent write-up. I wish I'd had this when I did the
introductory courses at my dayjob. With those simple commands, 90%
of the users get access to 90% of the usefulness of git, imo. And,
more importantly, it's enough to get them started right away.
> The pace needed to be adjusted to the users, in my experience, but not the
> order.
>
> Now, it makes me really, really sad that Git has a reputation of being
> complicated, but I regularly hear from _my_ users that they do not
> understand how that came about.
>
> Am I the only one who deems teaching plumbing to users ("I like it raw!
> So I teach it the same way!") harmful?
>
I wholeheartedly agree. Telling people about "git rev-list" on day one
is probably the single greatest mistake I've ever done wrt git. To the
non-gitizen, it takes some mumbo-jumbo arguments and spits out a long
list of mumbo-jumbo output. Had I started with "git log" instead, it
would have been infinitely easier to explain how each commit has a
totally unique name.
In addition, I'd recommend setting
color.branch=auto
color.diff=auto
color.pager=true
color.status=true
before starting the "course". It makes the learning experience a whole
lot nicer.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Jakub Narebski @ 2008-07-18 8:45 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>
"Nigel Magnay" <nigel.magnay@gmail.com> writes:
> On Thu, Jul 17, 2008 at 7:22 PM, Petr Baudis <pasky@suse.cz> wrote:
>> On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
>>> And it works, but
>>>
>>> $ git pull fred
>>> $ git submodule update
>>>
>>> Can leave you with problems, because if a submodule wasn't pushed to
>>> origin, you won't have it available. This is because the commands are
>>> equivalent to
>>>
>>> $ git pull fred
>>> for each submodule()
>>> cd submodule
>>> git fetch origin
>>> git checkout <sha1>
> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
>
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
>
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
>
> I'm trying to improve the UI for projects using submodules to make it
> mostly transparent; the best way I can come up with is to pick on
> individual usecases and show that they're a particular pain and that
> perhaps they don't need to be.
I _think_ that you can currently work around this problem by using
URL rewriting (url.<base>.insteadOf).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-18 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk01hqzz.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
> + Teach git-merge -X<option> again.
> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
> + builtin-merge.c: use parse_options_step() "incremental parsing"
> machinery
> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>
> This needs to be merged to master iff/when merge-theirs gets merged,
> but I do not think this series is widely supported, so both are on hold.
Why do you say it is not widely supported? I may be wrong but I think you developed these patches after somebody from the mailing list asked for this feature.
You may find out people are enthusiastic about this only after you merge it to your master branch.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Junio C Hamano @ 2008-07-18 9:00 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nigel Magnay, Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <m363r3y42v.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> "Nigel Magnay" <nigel.magnay@gmail.com> writes:
>
>> Fred is a person (and != origin). His tree(s) are entirely correct and
>> consistent, and he doesn't yet wish to push to origin (and perhaps he
>> cannot, because he does not have permission to do so).
>> ...
> I _think_ that you can currently work around this problem by using
> URL rewriting (url.<base>.insteadOf).
Doesn't it also involve config modification?
I think the right thing to do for this kind of "trial merge" should be the
same as cases that do not involve submodules. You *DO NOT* give a handy
way to muck with your configuration to make "origin" point at fred.
Instead, you would do something like:
$ git fetch ../fred master
$ git checkout FETCH_HEAD
... review test fix ...
... when you are done, go back, discarding the state from Fred
$ git checkout master
What submodule changes from the above workflow would be what happens after
you switch to the trial state (the above example detaches HEAD temporarily
while peeking into Fred's history). It is understandable that you would
want to script something that recurses into the submodules that you have
checked out (or submodules that Fred wants you to look at), do the
equivalent of "git fetch ../fred" you did at the toplevel to automate that
step, but I very much agree with Pasky here in that it feels very wrong to
hijack "submodule update" for it.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Jakub Narebski @ 2008-07-18 9:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nigel Magnay, Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vwsjj8t3s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> [...] It is understandable that you would
> want to script something that recurses into the submodules that you have
> checked out (or submodules that Fred wants you to look at), do the
> equivalent of "git fetch ../fred" you did at the toplevel to automate that
> step, but I very much agree with Pasky here in that it feels very wrong to
> hijack "submodule update" for it.
There were two proposals how to deal with fetching all submodules:
(a) git-submodule recursing into submodules, IIRC even with some
implementation (b) new "git submodule fetch" command.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Re* git-remote SEGV on t5505 test.
From: SungHyun Nam @ 2008-07-18 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5fjd7x5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> SungHyun Nam <namsh@posdata.co.kr> writes:
>>
>>> Is it possible that we can use 'SHELL_PATH' here?
>> It is not just possible but we really should. There are other test
>> scripts that use hardcoded /bin/sh, but by setting SHELL_PATH the user is
>> already telling us that what the vendor has in /bin/sh isn't adequately
>> POSIX enough, and we really should try to honor that.
>>
>> "git grep -n /bin/sh t/t*sh | grep -v ':1:#!'" would tell you which ones
>> are suspect.
>
> SungHyun, I did not test this patch myself (all my shells grok $() command
> substitutions), so I won't be committing this until/unless I see a "tested
> on system X and works fine".
I tested it on Solaris and works fine. ^^
$ uname -sro
SunOS 5.9 Solaris
$ SHELL_PATH=/bin/bash bash ./t9001-send-email.sh
* ok 1: prepare reference tree
* ok 2: Setup helper tool
* ok 3: Extract patches
* ok 4: Send patches
* ok 5: Verify commandline
* ok 6: Show all headers
* ok 7: reject long lines
* ok 8: no patch was sent
* ok 9: allow long lines with --no-validate
* ok 10: Invalid In-Reply-To
* ok 11: Valid In-Reply-To when prompting
* ok 12: setup fake editor
* ok 13: --compose works
* ok 14: first message is compose text
* ok 15: second message is patch
* ok 16: sendemail.cc set
* ok 17: sendemail.cc unset
* ok 18: --compose adds MIME for utf8 body
* ok 19: --compose respects user mime type
* ok 20: --compose adds MIME for utf8 subject
* passed all 20 test(s)
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-18 9:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080718175040.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>> + Teach git-merge -X<option> again.
>> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>> + builtin-merge.c: use parse_options_step() "incremental parsing"
>> machinery
>> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>>
>> This needs to be merged to master iff/when merge-theirs gets merged,
>> but I do not think this series is widely supported, so both are on hold.
>
> Why do you say it is not widely supported? I may be wrong but I think
> you developed these patches after somebody from the mailing list asked
> for this feature.
Well, for one thing, I do not believe in their cause. As I wrote in the
log messages for these commits (actually not these above which is a series
for merge fixup, but the other topic), I do not think it is a sensible
thing to say "let's take as much automerge results as possible to salvage
our changes where they do not overlap with what the upstream did, but I
would give up our changes to places that the upstream also touched,
because I do not understand what they did well enough to be able to
resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
that.
That also was the reason I did not add any documentation to it. But I do
like the change to the infrastructure to allow passing strategy-specific
options through git-merge and git-pull. Perhaps I should write something
up, if only to salvage that -X<option> part, even though I am very much
inclined to discard -Xtheirs (and -Xours) part.
^ permalink raw reply
* Re: Re* git-remote SEGV on t5505 test.
From: Junio C Hamano @ 2008-07-18 9:13 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <48805D65.1060704@posdata.co.kr>
SungHyun Nam <namsh@posdata.co.kr> writes:
>> SungHyun, I did not test this patch myself (all my shells grok $() command
>> substitutions), so I won't be committing this until/unless I see a "tested
>> on system X and works fine".
>
> I tested it on Solaris and works fine. ^^
Thanks.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-18 9:16 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>
Hi,
_please_, trim the parts of quoted e-mails that you are not reacting
to. It makes your mails easier to read.
On Fri, Jul 18, 2008 at 09:11:53AM +0100, Nigel Magnay wrote:
> No.
> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
>
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
>
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
Ok! Handling this case makes sense, though I would have wished you to
word this use case this clearly from the beginning; or maybe I'm just
slow. :-)
Now, we (at least we two) agree that this use case is worth supporting,
I still don't like the solution you propose, though. The problem that we
are trying to solve is:
"How do we mass-supply custom submodule URLs when publishing the
customized main repository at a custom location too?"
Now, the most natural solution is for Fred to actually customize
.gitmodules content when committing the submodule updates:
(i) Either just give submodule update a hypothetical flag that will
ignore .git/config for that particular run or,
(ii) even much better, actually change logical submodule names in
.gitmodules; this is appropriate as you want the modules to actually
point at a significantly different repository. Thus,
[submodule "boo"]
path=boo
url=git://repo.or.cz/boo.git
will become
[submodule "boo/fred"]
path=boo
url=git://repo.or.cz/boo/fred.git
Also, you will be able to redefine the URL of boo/fred too in
.git/config (e.g. you're behind a firewall that lets only HTTP
through; I'm actually behind such a firewall these days at my
(non-SUSE ;) work).
This should be reasonably elegant, works with no Git changes, however
still has one significant problem - you very much do not want such a
.gitmodules change in any of the commits you merge, since it breaks
bisectability in case Fred or his repositories go away.
In that case, several possibilities come up on my mind:
(1) Fred will prepare special branch for testing with modified
.gitmodules and then for a merge he offers a different branch with clean
.gitmodules. This works, but it is obnoxious.
(2) Fred will pass a patch for .gitmodules as a part of his review
request. This works too and is obnoxious in slightly different aspects
than (1).
(3) Fred will offer a rewrite rule that you will pass to submodule
update, like your solution proposed, but much more universal so that it
is not tailored just to your particular repository hierarchy. A simple
sed script could work fine.
(4) Something else that I'm not realizing.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-18 9:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Petr Baudis, Johannes Schindelin,
Git Mailing List
In-Reply-To: <200807181107.18098.jnareb@gmail.com>
On Fri, Jul 18, 2008 at 10:07 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
>> [...] It is understandable that you would
>> want to script something that recurses into the submodules that you have
>> checked out (or submodules that Fred wants you to look at), do the
>> equivalent of "git fetch ../fred" you did at the toplevel to automate that
>> step, but I very much agree with Pasky here in that it feels very wrong to
>> hijack "submodule update" for it.
>
> There were two proposals how to deal with fetching all submodules:
> (a) git-submodule recursing into submodules, IIRC even with some
> implementation (b) new "git submodule fetch" command.
>
Yes - I think there's a few more options and possible combinations
a. git submodule update having <repository> <refspec> to recurse into
submodules (a)(original patch)
b. git submodule fetch
c. git fetch --submodules
d. git fetch (automatically recurse if there are submodules)
e. git fetch (automatically recurse if there is some setting in .git/config)
I started at (a) and agree that it's a bad choice.
Any of b-e would work for me.
My (personal) preferences would be for d/e, then c, then b - but -
that's based on my belief that submodules are a pretty fundamental
thing and having a separate UI is bad.
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Nick Andrew @ 2008-07-18 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvzeojm.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 17, 2008 at 10:42:21PM -0700, Junio C Hamano wrote:
> Thanks for noticing, but this replaces one breakage with another.
>
> Your new behaviour is a new "tell me if it is an empty set" option, and it
> means quite different thing from what --quiet does.
Fair enough. Yes, I want to find out if it is an empty set. The
manpage does say "fully connected" which I interpreted to mean
that one set of commits is a subset of the other..
I want to automatically (e.g. in crontab) update a git repo to the latest
HEAD from a remote branch ... but with the possibility that the local
repo has local changes, and I want no chance of merge failure. In other
words, "git fetch remote; git merge origin/master" and only do the
merge if it's a fast-forward. If there are any local commits, or local
uncommitted changes, then leave the local working tree alone.
So my idea was to use "git rev-list --quiet master ^origin/master"
and check the exit code; if zero do "git merge origin/master". Without
a working "--quiet" nor exit code I can pipe the output to "wc -l"
but is there a more efficient/reliable way to implement the requirement?
Nick.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-18 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr69r8sqk.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Well, for one thing, I do not believe in their cause. As I wrote in the
> log messages for these commits (actually not these above which is a series
> for merge fixup, but the other topic), I do not think it is a sensible
> thing to say "let's take as much automerge results as possible to salvage
> our changes where they do not overlap with what the upstream did, but I
> would give up our changes to places that the upstream also touched,
> because I do not understand what they did well enough to be able to
> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
> that.
I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
> That also was the reason I did not add any documentation to it. But I do
> like the change to the infrastructure to allow passing strategy-specific
> options through git-merge and git-pull. Perhaps I should write something
> up, if only to salvage that -X<option> part, even though I am very much
> inclined to discard -Xtheirs (and -Xours) part.
I think such a documentation will help people to decide if 'theirs' option makes sense for their workflow.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-18 9:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080718091608.GL10151@machine.or.cz>
On Fri, Jul 18, 2008 at 10:16 AM, Petr Baudis <pasky@suse.cz> wrote:
> snip
>
> "How do we mass-supply custom submodule URLs when publishing the
> customized main repository at a custom location too?"
>
Yes - that is an additional problem.
If I may expand the usecase just so it's clear (and to check we're
talkiing the same language)
I do something like
$ git remote add fred git://fredcomputer/superproject/.git
$ git fetch --submodules fred
And when the recursive fetching enters a submodule, it is trying
itself to do something like
$ git fetch fred
At which point
1) the submodule also has a remote specified for fred. In which case
it can continue
2) the submodule doesn't have remote specified for fred. How to solve
this case? (I.E how does 'my' git 'discover' where fred's git
repositories are for the submodules?)
a) By getting some information from fred, either in *Fred's*
superproject .git/config (or some other readable file)
b) By reading some information out of the superproject .gitmodules
that has been fetched from fred
c) By calculating a relative URL based on the supposition that fred
has working copies laid out in the filesystem.
I was tentatively suggesing (c), with a backup of (a) for the minority
cases where you weren't pulling from a person but from a mirror or
something. Having the client edit config files just feels like a hack
to me, regardless of whether scripts are enabled to do it.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-18 9:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080718182010.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> ... I do not think it is a sensible
>> thing to say "let's take as much automerge results as possible to salvage
>> our changes where they do not overlap with what the upstream did, but I
>> would give up our changes to places that the upstream also touched,
>> because I do not understand what they did well enough to be able to
>> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
>> that.
>
> I do not know if "I do not understand what they did well enough" is the
> only reason people would want to use that feature. Isn't it better to
> let people decide that for themselves?
We have been saying that we will give long enough rope to people, but at
the same time I believe there are things that the world is better without,
and a feature that would only encourage a bad workflow is one of them.
The way I try to tell such a (mis)feature from a feature that can be
useful to people other than myself is to ask people why they would want
such a feature and what their response to possible downsides of such a
feature.
Don't get me wrong. Choice is good, and it is also good that some people
may choose differently from me. After all, we are different people with
different workflows.
But they should be able to explain the reason why they choose something
clearly, at least well enough to convince themselves to choose it. If
they can't come up with a rational explanation, it becomes an irrational
"because I want to" (and "because I can, now that you have already coded
it"). That leads to feeping creaturism and a bad feature that the world
is better without.
I haven't heard an explanation other than the one I said above, and I do
not think that explanation is rational.
Side note. Even though I invented rerere and it turned out to be a
great ti[mp]esaver, I do want to validate the reused resolution
makes sense in the new context every time rerere does its job.
Recently Ingo wanted the auto resolution to be staged
automatically, and rerere.autoupdate was born. I was initially
very much against it, but his description of the workflow where it
would be useful was convincing enough. This "convincing" does not
have to be "Yeah, it's useful to me as well; thanks for explaining
it to me". Even though my workflow might never be helped with
such a feature, I can see that the different workflow he presented
would be useful to people other than myself, and I could agree
that the new feature would help such a workflow. This was a good
example of "choosing something I initially thought would be
detrimental with a good reason, and with a good explanation making
me realize that my initial thought was too narrow".
> I think such a documentation will help people to decide if 'theirs'
> option makes sense for their workflow.
So here it is.
-- >8 --
[PATCH] Document that merge strategies can now take their own options
Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path]
options to the merge-recursive strategy.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/merge-options.txt | 4 ++++
Documentation/merge-strategies.txt | 26 ++++++++++++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index ffbc6e9..96aec48 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -58,3 +58,7 @@
If there is no `-s` option, a built-in list of strategies
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+
+-X<option>::
+ Pass merge strategy specific option through to the merge
+ strategy.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..39ff0a8 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,6 +1,11 @@
MERGE STRATEGIES
----------------
+The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+backend 'merge strategies' to be chosen with `-s` option. Some strategies
+can also take their own options, which can be passed by giving `-X<option>`
+arguments to 'git-merge' and/or 'git-pull'.
+
resolve::
This can only resolve two heads (i.e. the current branch
and another branch you pulled from) using 3-way merge
@@ -20,6 +25,27 @@ recursive::
Additionally this can detect and handle merges involving
renames. This is the default merge strategy when
pulling or merging one branch.
++
+The 'recursive' strategy can take the following options:
+
+ours;;
+ This option forces conflicting hunks to be auto-resolved cleanly by
+ favoring 'our' version. Changes from the other tree that do not
+ conflict with our side are reflected to the merge result.
++
+This should not be confused with the 'ours' merge strategy, which does not
+even look at what the other tree contains at all. IOW, it discards everything
+the other tree did, declaring 'our' history contains all that happened in it.
+
+theirs;;
+ This is opposite of 'ours'.
+
+subtree[=path];;
+ This option is a more advanced form of 'subtree' strategy, where
+ the strategy makes a guess on how two trees must be shifted to
+ match with each other when merging. Instead, the specified path
+ is prefixed (or stripped from the beginning) to make the shape of
+ two trees to match.
octopus::
This resolves more than two-head case, but refuses to do
--
1.5.6.3.573.gd2d2
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Petr Baudis @ 2008-07-18 9:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20080718182010.6117@nanako3.lavabit.com>
On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
It is dangerous to introduce new options just because we think someone,
sometimes might find it useful, especially if they potentially encourage
a bad workflow. Adding options and commands is expensive since it
complicates the UI further, thus we should add further only when we have
good reason for it.
> > That also was the reason I did not add any documentation to it.
I was actually looking for something like this based on some question on
#git (about git pull -s theirs possibility), and did stumble upon these
patches, but quickly gave up on them since it wasn't immediately clear
for me from the patch description exactly how the workflow looks like
(it doesn't really seem to work like the opposite of -s ours nor is it a
separate strategy... huh) and the options were completely undocumented.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]
From: Michael J Gruber @ 2008-07-18 9:55 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807171940160.8986@racer>
Johannes Schindelin venit, vidit, dixit 17.07.2008 20:43:
> Hi,
>
> On Thu, 17 Jul 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>>> Is there a way to commit the contents of a tarball without using
>>>> plumbing? I occasionally want to track an upstream that I know only
>>>> as a series of tarballs, so I do something like:
>>>>
>>>> cd repo/
>>>> git checkout upstream
>>>> rm -rf *
>>>> tar -xzvf ../new-version.tar.gz
>>> How about "git add -u" and "git add ."?
>> It would work only if new version never removes files.
>
> You made me doubt for a second there. But "git add -u" updates the index
> when a tracked files was deleted. So after "rm -rf *", "git add -u" would
> empty the index.
This brings me to a question I never dared to ask so far. In fact, I'm
happy with git-add and using the index explicitly rather than
implicitly. Still, sometimes I find my self wanting an "addremove", such
as in a situation like above. (E.g., tracking a dir which is synced by
different means.)
Say I have a modified file a, removed file b (rm'ed, not git-rm'ed) and
a new file c. Then:
git add . would add the changes to a and c
git add -u would add the changes to a and (the removal of) b
git commit -a would commit the changes to a and b (it does add -u + commit)
So, if I want to add and commit all three kinds of changes using
porcelaine I have to do:
git add .
git commit -a
or
git add .
git add -u
git commit
AFAICT this means that git will scan for modifications to tracked files
which still exist twice. While this will be noticeable only with large
dirs on slow FS it's conceptually not so nice. Is there any (porc.) way
around? I don't know the internals, though; maybe there's no second scan
(stat...).
Cheers
Michael
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-18 9:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080718094404.GB32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
>> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
>
> It is dangerous to introduce new options just because we think someone,
> sometimes might find it useful, especially if they potentially encourage
> a bad workflow. Adding options and commands is expensive since it
> complicates the UI further, thus we should add further only when we have
> good reason for it.
>
>> > That also was the reason I did not add any documentation to it.
>
> I was actually looking for something like this based on some question on
> #git (about git pull -s theirs possibility), and did stumble upon these
> patches, but quickly gave up on them since it wasn't immediately clear
> for me from the patch description exactly how the workflow looks like
> (it doesn't really seem to work like the opposite of -s ours nor is it a
> separate strategy... huh) and the options were completely undocumented.
Heh, now you have some readings to do ;-)
I tried not to sound too negative when describing -Xours and -Xtheirs
there, but actually I think "-s theirs" is even worse. It is how you
would discard what you did (perhaps because the other side has much better
solution than your hack), but that can be much more easily and cleanly
done with:
$ git reset --hard origin
Some poeple might say "But with 'merge -s theirs', I can keep what I did,
too". That reset is simply discarding what I did.
That logic also is flawed. You can instead:
$ git branch i-was-stupid
$ git reset --hard origin
if you really want to keep record of your failure.
One big problem "-s theirs" has, compared to the above "reset to origin,
discarding or setting aside the failed history" is that your 'master'
history that your further development is based on will keep your failed
crap in it forever if you did "-s theirs". Hopefully you will become a
better programmer over time, and you may eventually have something worth
sharing with the world near the tip of your master branch. When that
happens, however, you _cannot_ offer your master branch to be pulled by
the upstream, as the wider world will not be interested in your earlier
mistakes at all.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-18 10:00 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180236u4e7f5f9bm81b702d14c052de8@mail.gmail.com>
On Fri, Jul 18, 2008 at 10:36:51AM +0100, Nigel Magnay wrote:
> On Fri, Jul 18, 2008 at 10:16 AM, Petr Baudis <pasky@suse.cz> wrote:
> > snip
> >
> > "How do we mass-supply custom submodule URLs when publishing the
> > customized main repository at a custom location too?"
> >
> Yes - that is an additional problem.
Wait, I'm lost again - _additional_ problem? How does it differ from the
_original_ problem, how does it differ from what you're explaining below
and how does what you're explaining below differ from the original
problem?
Or are we talking exclusively about what I summed up above now?
> If I may expand the usecase just so it's clear (and to check we're
> talkiing the same language)
>
> I do something like
> $ git remote add fred git://fredcomputer/superproject/.git
> $ git fetch --submodules fred
I think you mean git pull --submodules fred. Well, actually, you want to
pull the main repository, then submodule update (_not_ pull in the
submodules). See? This is part of the "semantic swamp" I mentioned
before.
I think it should be somehow part of the _main_ project's fred branch
that in this branch, the subprojects should be fetched from a different
location; thus, you would still do
$ git remote add fred git://fredcomputer/superproject/.git
$ git pull fred
$ git submodule update
where either the submodule update takes the info from fred's adjusted
.gitmodules, or it is an implicit part of the branch as in fred tells
you to run the update command with some extra arguments.
However, I still believe the information should primarily stem from the
main repository; consider e.g. if you do not have some of the submodules
checked out when you switch to fred, then figure out that in fred's
branch, you really do want them checked out.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]
From: Michael J Gruber @ 2008-07-18 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807161804400.8950@racer>
Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:
...
>
> Am I the only one who deems teaching plumbing to users ("I like it raw!
> So I teach it the same way!") harmful?
>
> Ciao,
> Dscho "who is sad"
In an attempt at making not only Dscho happier I suggest a restructuring
of the man pages in the following way:
In each man page, put a note which says something like:
"This is part of linkgit:gitplumbing[7]." and the like
It should be in a prominent place, such as the last line of "DESCRIPTION".
gitplumbing[7] etc. pages should contain:
- a definition of the respective term together with appropriate usage
advice (regular use/scripting..., "Let there be dragons.")
- a list of commands like we have in git[1] right now
With the current situation, people don't look at git[1] in order to find
out what they're supposed to use. It's too long anyways, and could link
the above pages instead.
If there's enough interest/agreement I'd come up with a refactoring patch.
Michael
P.S.: For me
porcellaine = artistic, fragile
plumbing = plain, robust
Which one would you choose for daily hard work? ;)
^ permalink raw reply
* Git Branding Overview, Re: Git.or.cz Experimental Design
From: Petr Baudis @ 2008-07-18 10:39 UTC (permalink / raw)
To: David Baldwin; +Cc: git
In-Reply-To: <5fb1d2400807022011w7f8d79dbk68a64dc1b8b01d98@mail.gmail.com>
Hi,
On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
> Hello Petr:
> I hope you are doing well. I was looking at the git.or.cz site tonight and
> thought it could perhaps use a little freshening up from a design
> standpoint. Therefore, I messed around with the default stylesheet and the
> home page a bit and made a logo. You can take a look at the experimental
> design at this address...
> http://baldwindev.com/git.or.cz/
>
> It's really just a few little changes. If you're interested in implementing
> any of this into the current site, feel free to grab the changes from my
> github git repository. You can see the few text changes in the diff...
> http://github.com/bilson/gitorcz_redesign/tree/master
I'm not sure if this is really an improvement on the current state,
but then again, the current state pretty much matches my idea and maybe
others will agree that your proposal is better. Thus, it's better to
show this to the Git community at large. :-)
If you or anyone is shooting for a re-design, I would suggest to
somehow relate to the current "Git brandings" in use:
http://git.or.cz/git-logo.png
http://henrik.nyh.se/uploads/git-logo.png
If you think you have a cooler logo, that's fine too, but then it's
again better to present it explicitly, I believe. The latter is used
especially within mSysGit, the former is used more widely - at the
current homepage, as Gitweb logo, and in various modifications like
http://git.nyh.se/git-favicon.png
http://members.cox.net/junkio/git.png
http://unfuddle.com/images/screens/source.big.jpg
(top left ;)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Johannes Schindelin @ 2008-07-18 10:50 UTC (permalink / raw)
To: Nick Andrew; +Cc: Junio C Hamano, git
In-Reply-To: <20080718092001.GD16102@mail.local.tull.net>
Hi,
On Fri, 18 Jul 2008, Nick Andrew wrote:
> I want to automatically (e.g. in crontab) update a git repo to the
> latest HEAD from a remote branch ... but with the possibility that the
> local repo has local changes, and I want no chance of merge failure. In
> other words, "git fetch remote; git merge origin/master" and only do the
> merge if it's a fast-forward. If there are any local commits, or local
> uncommitted changes, then leave the local working tree alone.
>
> So my idea was to use "git rev-list --quiet master ^origin/master" and
> check the exit code; if zero do "git merge origin/master". Without a
> working "--quiet" nor exit code I can pipe the output to "wc -l" but is
> there a more efficient/reliable way to implement the requirement?
Yes. Check if "$(git rev-parse master)" is different from "$(git rev-parse
origin/master)" (to avoid unnecessary merging), and then that "$(git
merge-base master origin/master)" is equal to "$(git rev-parse master)".
Note: this is plumbing, meant for scripting (which is exactly your
scenario). Do not teach this to new Git users.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Link git-shell only to a subset of libgit.a
From: Johannes Schindelin @ 2008-07-18 10:55 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Stephan Beyer, Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <20080718060321.GJ2925@dpotapov.dyndns.org>
Hi,
On Fri, 18 Jul 2008, Dmitry Potapov wrote:
> On Fri, Jul 18, 2008 at 03:04:30AM +0200, Stephan Beyer wrote:
> > Commit 5b8e6f85 introduced stubs for three functions that make no
> > sense for git-shell. But those stubs defined libgit.a functions a
> > second time so that a linker can complain.
> >
> > Now git-shell is only linked to a subset of libgit.a.
> >
> > Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
>
> I agree, it is probably better to specify explicitly what files to link
> for git-shell if we want to keep it small and avoid the problem with
> some linkers.
It is also more elegant in general, as it does not play tricks to do what
we want, but it does explicitely what we want.
FWIW I only removed almost the exact launch_editor() patch Stephan posted
from my personal Git fork because of this trickery (which I did not have
the time to fix).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-18 11:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080718100048.GN10151@machine.or.cz>
On Fri, Jul 18, 2008 at 11:00 AM, Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Jul 18, 2008 at 10:36:51AM +0100, Nigel Magnay wrote:
>> On Fri, Jul 18, 2008 at 10:16 AM, Petr Baudis <pasky@suse.cz> wrote:
>> > snip
>> >
>> > "How do we mass-supply custom submodule URLs when publishing the
>> > customized main repository at a custom location too?"
>> >
>> Yes - that is an additional problem.
>
> Wait, I'm lost again - _additional_ problem? How does it differ from the
> _original_ problem, how does it differ from what you're explaining below
> and how does what you're explaining below differ from the original
> problem?
>
In addition to the problem of needing to execute multiple commands and
edit files to acheive what is a rather simple usecase, there is the
additional problem of discovering (for a third party) a url for where
their submodules are stored.
> Or are we talking exclusively about what I summed up above now?
>
In this part of the thread. The first part seems to have broad
agreement that a command could be added / modified, but not yet what
it should look like.
>> If I may expand the usecase just so it's clear (and to check we're
>> talkiing the same language)
>>
>> I do something like
>> $ git remote add fred git://fredcomputer/superproject/.git
>> $ git fetch --submodules fred
>
> I think you mean git pull --submodules fred. Well, actually, you want to
> pull the main repository, then submodule update (_not_ pull in the
> submodules). See? This is part of the "semantic swamp" I mentioned
> before.
Ah - I understand. You're saying "you can't pull submodules when you
pull the supermodule, because you don't know which submodules might be
needed until you also merge / checkout the desired revision" ?
Ack.
>
> I think it should be somehow part of the _main_ project's fred branch
> that in this branch, the subprojects should be fetched from a different
> location; thus, you would still do
>
> $ git remote add fred git://fredcomputer/superproject/.git
> $ git pull fred
> $ git submodule update
>
Yes, that makes sense.
> where either the submodule update takes the info from fred's adjusted
> .gitmodules, or it is an implicit part of the branch as in fred tells
> you to run the update command with some extra arguments.
>
> However, I still believe the information should primarily stem from the
> main repository; consider e.g. if you do not have some of the submodules
> checked out when you switch to fred, then figure out that in fred's
> branch, you really do want them checked out.
>
Yes.
Referring to your earlier mail, I'm now preferring "(4) Something else
that I'm not realizing." ;-)
Hm. It feels like each person could have some 'local' info in their
.gitmodules, and rules around merging; but I'm not sure of exactly
what, or how.
^ permalink raw reply
* [PATCH] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-18 11:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0807180313200.2906@eeepc-johanness>
This patch removes exit()/die() calls and builtin-specific messages
from launch_editor(), so that it can be used as a general libgit.a
function to launch an editor.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Is that ok? :)
builtin-commit.c | 4 +++-
builtin-tag.c | 4 +++-
editor.c | 21 ++++++++++++---------
strbuf.h | 2 +-
4 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index ed3fe3f..64f69f3 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -647,7 +647,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
char index[PATH_MAX];
const char *env[2] = { index, NULL };
snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
- launch_editor(git_path(commit_editmsg), NULL, env);
+ if (launch_editor(git_path(commit_editmsg), NULL, env))
+ die("running editor failed.\n"
+ "Please supply the message using either -m or -F option.");
}
if (!no_verify &&
diff --git a/builtin-tag.c b/builtin-tag.c
index 219f51d..3b7a25e 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -295,7 +295,9 @@ static void create_tag(const unsigned char *object, const char *tag,
write_or_die(fd, tag_template, strlen(tag_template));
close(fd);
- launch_editor(path, buf, NULL);
+ if (launch_editor(path, buf, NULL))
+ die("running editor failed.\n"
+ "Please supply the message using either -m or -F option.");
unlink(path);
free(path);
diff --git a/editor.c b/editor.c
index 483b62d..5d7f5f9 100644
--- a/editor.c
+++ b/editor.c
@@ -2,7 +2,7 @@
#include "strbuf.h"
#include "run-command.h"
-void launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
+int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
{
const char *editor, *terminal;
@@ -17,9 +17,8 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
terminal = getenv("TERM");
if (!editor && (!terminal || !strcmp(terminal, "dumb"))) {
fprintf(stderr,
- "Terminal is dumb but no VISUAL nor EDITOR defined.\n"
- "Please supply the message using either -m or -F option.\n");
- exit(1);
+ "Terminal is dumb but no VISUAL nor EDITOR defined.\n");
+ return 1;
}
if (!editor)
@@ -28,6 +27,7 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
if (strcmp(editor, ":")) {
size_t len = strlen(editor);
int i = 0;
+ int failed;
const char *args[6];
struct strbuf arg0;
@@ -43,14 +43,17 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
args[i++] = path;
args[i] = NULL;
- if (run_command_v_opt_cd_env(args, 0, NULL, env))
- die("There was a problem with the editor %s.", editor);
+ failed = run_command_v_opt_cd_env(args, 0, NULL, env);
strbuf_release(&arg0);
+ if (failed)
+ return error("There was a problem with the editor %s.",
+ editor);
}
if (!buffer)
- return;
+ return 0;
if (strbuf_read_file(buffer, path, 0) < 0)
- die("could not read message file '%s': %s",
- path, strerror(errno));
+ return error("could not read file '%s': %s",
+ path, strerror(errno));
+ return 0;
}
diff --git a/strbuf.h b/strbuf.h
index 0c6ffad..eba7ba4 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -123,6 +123,6 @@ extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
extern int strbuf_getline(struct strbuf *, FILE *, int);
extern void stripspace(struct strbuf *buf, int skip_comments);
-extern void launch_editor(const char *path, struct strbuf *buffer, const char *const *env);
+extern int launch_editor(const char *path, struct strbuf *buffer, const char *const *env);
#endif /* STRBUF_H */
--
1.5.6.3.390.g7b30
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-18 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7v63r38r4r.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 18 Jul 2008, Junio C Hamano wrote:
> +The 'recursive' strategy can take the following options:
> +
> +ours;;
You still have not addressed the issue that you can specify multiple
strategies, or even a single _wrong_ one. So:
$ git merge -s stupid -Xours
would not fail at all, but definitely not do the right thing either (it
disobeys a direct command of the user).
Apart from having to choose different -X option names for the different
backends, to avoid them from clashing when you specify multiple
strategies, you also deprive the user from being able to try the _same_
backend with different options.
IOW all my objections to the -X option (even that it does not fit with our
short option parsing paradigm) still apply.
We already have the "-S" wart, let's not add to that pile.
Ciao,
Dscho
^ 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