* 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
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-18 11:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20080718175040.6117@nanako3.lavabit.com>
Hi,
On Fri, 18 Jul 2008, Nanako Shiraishi wrote:
> 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.
Asking for a feature, and then not doing a single thing to defend why it
makes sense, of a single person, who does not even speak up now, does not
count for "wide support".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] editor.c: Libify launch_editor()
From: Johannes Schindelin @ 2008-07-18 12:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <1216380408-21671-1-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 18 Jul 2008, Stephan Beyer wrote:
> 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.
Thanks. Now we have to convince Junio that it is a good idea :-)
> 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.");
In the error case, run_editor() already said more than "running editor
failed.", right? Maybe you just want to skip that line and keep the
second?
> diff --git a/editor.c b/editor.c
> index 483b62d..5d7f5f9 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -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;
Why not "return error()"?
Rest looks obviously correct to me!
Thanks,
Dscho
^ permalink raw reply
* [PATCH v2] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-18 12:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0807181405510.3932@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>
---
Hi,
Johannes Schindelin wrote:
> On Fri, 18 Jul 2008, Stephan Beyer wrote:
>
> > 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.
>
> Thanks. Now we have to convince Junio that it is a good idea :-)
>
> > 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.");
>
> In the error case, run_editor() already said more than "running editor
> failed.", right? Maybe you just want to skip that line and keep the
> second?
Well, I wanted to do it like that, but die_builtin() usually adds "fatal: ",
so the message becomes like:
error: There was a problem with the editor xxx.
fatal: Please supply the message using either -m or -F option.
^^^^^^^^^^^^^
That looks odd.
Btw, using the former patch, it is:
error: There was a problem with the editor xxx.
fatal: running editor failed.
Please supply the message using either -m or -F option.
So I wonder if I should not die() at all, but do a
fprintf(stderr, "Please supply the message using either -m or -F option.\n");
exit(1);
which is done in *this* version of the patch. So that the message becomes:
error: There was a problem with the editor 'xxx'.
Please supply the message using either -m or -F option.
> > diff --git a/editor.c b/editor.c
> > index 483b62d..5d7f5f9 100644
> > --- a/editor.c
> > +++ b/editor.c
> > @@ -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;
>
> Why not "return error()"?
I was unsure here, too, but you're right.
Regards.
builtin-commit.c | 6 +++++-
builtin-tag.c | 6 +++++-
editor.c | 24 ++++++++++++------------
foo | 1 +
strbuf.h | 2 +-
5 files changed, 24 insertions(+), 15 deletions(-)
create mode 100644 foo
diff --git a/builtin-commit.c b/builtin-commit.c
index ed3fe3f..23ec629 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -647,7 +647,11 @@ 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)) {
+ fprintf(stderr,
+ "Please supply the message using either -m or -F option.\n");
+ exit(1);
+ }
}
if (!no_verify &&
diff --git a/builtin-tag.c b/builtin-tag.c
index 219f51d..325b1b2 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -295,7 +295,11 @@ 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)) {
+ fprintf(stderr,
+ "Please supply the message using either -m or -F option.\n");
+ exit(1);
+ }
unlink(path);
free(path);
diff --git a/editor.c b/editor.c
index 483b62d..eebc3e9 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;
@@ -15,12 +15,8 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
editor = getenv("EDITOR");
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);
- }
+ if (!editor && (!terminal || !strcmp(terminal, "dumb")))
+ return error("Terminal is dumb but no VISUAL nor EDITOR defined.");
if (!editor)
editor = "vi";
@@ -28,6 +24,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 +40,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/foo b/foo
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+
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
* sparse checkout UI
From: Nguyen Thai Ngoc Duy @ 2008-07-18 13:03 UTC (permalink / raw)
To: Git Mailing List
Hi,
I gave up on subtree checkout, the cvs/svn way (making subtree
toplevel worktree). Instead I have been working on sparse checkout,
which better fits Git's "working at toplevel worktree" philosophy.
Things are shaping up, but I still have not figured out UI for
entering/leaving/updating sparse checkout.
Should it be an option for git-checkout, like "git checkout
--sparse=git-gui"? Or making it a separate command? git-clone may need
"--sparse-checkout" option anyway, to be able to do sparse checkout
from the beginning.
Opinions?
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Petr Baudis @ 2008-07-18 13:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4lcfgoo.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, Jul 17, 2008 at 12:34:31PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I'm not sure if I should resend the updated patch, or if you already
> > included your comments yourself.
>
> When I send my review comments out, I generally expect an updated version,
> unless I explicitly say "will apply with tweaks, no need to resend".
ok, that is pretty much what I expected, I just wanted to avoid doing
duplicate work. :-)
..snip..
> yes, I am strongly hinting to drop that description; it
> is not even remotely interesting
I have tried to salvage the now-subsection for a while yet, but
ultimately, I now feel as well that it is not worth it; the meat of it
can be summed up in a single sentence that I have re-added to the main
section.
> However, I think we may want to talk about "How to tell if your merge did
> not even touch your index nor working tree" somewhere in the manual.
> "When there are conflicts, these things happen" part talks about how to
> resolve conflicts, but when merge refuses to avoid losing local changes,
> the instruction in that part does not apply.
I'm not sure if this is worth pondering about? The action would feel
rather obvious to me - get rid of the local changes somehow, either
committing them or stashing them or wiping them out. Is that worth
elaborating, or is there more to it?
--
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
* [PATCH] Documentation/git-merge.txt: Partial rewrite of How Merge Works
From: Petr Baudis @ 2008-07-18 13:20 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <20080718131800.GP10151@machine.or.cz>
The git-merge documentation's "HOW MERGE WORKS" section is confusingly
composed and actually omits the most interesting part, the merging of
the arguments into HEAD itself, surprisingly not actually mentioning
the fast-forward merge anywhere.
This patch replaces the "[NOTE]" screenful of highly technical details
by a single sentence summing up the interesting information, and instead
explains how are the arguments compared with HEAD and the three possible
inclusion states that are named "Already up-to-date", "Fast-forward"
and "True merge". It also makes it clear that the rest of the section
talks only about the true merge situation.
Junio initiated the removal of the Note screenful altogether and
offered many stylistical fixes.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-merge.txt | 69 ++++++++++++++++---------------------------
1 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 019e4ca..77c62aa 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -57,50 +57,31 @@ HOW MERGE WORKS
A merge is always between the current `HEAD` and one or more
commits (usually, branch head or tag), and the index file must
-exactly match the
-tree of `HEAD` commit (i.e. the contents of the last commit) when
-it happens. In other words, `git diff --cached HEAD` must
-report no changes.
-
-[NOTE]
-This is a bit of a lie. In certain special cases, your index is
-allowed to be different from the tree of the `HEAD` commit. The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-differences from your `HEAD` commit. Also, your index entries
-may have differences from your `HEAD` commit that match
-the result of a trivial merge (e.g. you received the same patch
-from an external source to produce the same result as what you are
-merging). For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
-
-Otherwise, merge will refuse to do any harm to your repository
-(that is, it may fetch the objects from remote, and it may even
-update the local branch used to keep track of the remote branch
-with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact). In addition,
-merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
-a problematic merge can be removed by using `git reset ORIG_HEAD`.
-
-You may have local modifications in the working tree files. In
-other words, 'git-diff' is allowed to report changes.
-However, the merge uses your working tree as the working area,
-and in order to prevent the merge operation from losing such
-changes, it makes sure that they do not interfere with the
-merge. Those complex tables in read-tree documentation define
-what it means for a path to "interfere with the merge". And if
-your local modifications interfere with the merge, again, it
-stops before touching anything.
-
-So in the above two "failed merge" case, you do not have to
-worry about loss of data --- you simply were not ready to do
-a merge, so no merge happened at all. You may want to finish
-whatever you were in the middle of doing, and retry the same
-pull after you are done and ready.
-
+match the tree of `HEAD` commit (i.e. the contents of the last commit)
+when it starts out. In other words, `git diff --cached HEAD` must
+report no changes. (One exception is when the changed index
+entries are already in the same state that would result from
+the merge anyway.)
+
+Three kinds of merge can happen:
+
+* The merged commit is already contained in `HEAD`. This is the
+ simplest case, called "Already up-to-date."
+
+* `HEAD` is already contained in the merged commit. This is the
+ most common case especially when involved through 'git pull':
+ you are tracking an upstream repository, committed no local
+ changes and now you want to update to a newer upstream revision.
+ Your `HEAD` (and the index) is updated to at point the merged
+ commit, without creating an extra merge commit. This is
+ called "Fast-forward".
+
+* Both the merged commit and `HEAD` are independent and must be
+ tied together by a merge commit that has them both as its parents.
+ The rest of this section describes this "True merge" case.
+
+The chosen merge strategy merges the two commits into a single
+new source tree.
When things cleanly merge, these things happen:
1. The results are updated both in the index file and in your
^ permalink raw reply related
* Re: [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Petr Baudis @ 2008-07-18 13:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heikki Orsila
In-Reply-To: <7v4p6ofedl.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 17, 2008 at 01:24:22PM -0700, Junio C Hamano wrote:
> Your lines are getting overlong to be easily quoted and commented...
I will watch for that.
> Petr Baudis <pasky@suse.cz> writes:
> > +.... In case you want to merge the project
> > +histories, possibly make local modifications within the tree, but also do not
> > +mind that your repository will bulk up with all the contents of the other
> > +project, consider adding a remote for the other project and using the 'subtree'
> > +merge strategy instead of setting up a submodule.
>
> I'd suggest rephrasing "do not mind" to something a lot less nagative.
> The user decides to merge because both histories *are* relevant and at
> that point there is no _minding_ anymore. If you want to have them, you
> not only "do not mind to have" them but you positively "want" them.
>
> On the other hand, a situation where you would want to use submodules is
> when not necessarily all users of the superproject would want to have all
> submodules cloned nor checked out. This needs to be stressed with equal
> weight as the above sentence in this "contrasting merged histories and
> submodules" paragraph. With that explained clearly upfront, it would
> become easier for the readers to understand why you can choose not to even
> update nor fetch submodules you are not interested in.
You are right. I have tried to reword the sentence to fix these issues.
> > +Submodules are composed from a special kind of tree entry (so-called `gitlink`)
> > +in the main repository that refers to a particular commit object within
>
> Do we have to say "special"? Is a gitlink any more special than blob and
> tree entries are? It tends to be rarer, it came later, but I do not think
> there is anything special from the end user's point of view.
Also the parenthesis look ugly, so I have reworded this to a simpler
formulation.
> > checked out and at appropriate revision in your working tree. You can inspect
> > the current status of your submodules using the 'submodule' subcommand and get
> > +an overview of the changes 'update' would perform using the 'summary'
> > +subcommand.
>
> Sorry, cannot parse the last three lines...
The mention of 'update' is confusing, and it was overally imprecise.
(I think that in general, the summary/status distinction was not a wise
UI decision.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Lea Wiemann @ 2008-07-18 13:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Petr Baudis
In-Reply-To: <200807180149.18565.jnareb@gmail.com>
Jakub Narebski wrote:
> [$commit->author:] We would probably want _in the future_ to return some
> object wrapper, which stringifies to value of author and committer headers
Yup, good idea. They'll even stay strings, they'll just be blessed.
>>>> +=item $commit->message
>
> I'd rather then have _git_ convert it to UTF=8 for us (using
> --encoding=<encoding> option to git-log/git-rev-list)
Yeah, I guess the API should actually decode it. You wouldn't want to
have the message in UTF-8 but in Unicode (I suggest you read man
perlunitut if you haven't done so). We cannot have git do the decoding,
since (apart from the fact that it doesn't smell right) it isn't
guaranteed to emit valid UTF-8 (thanks Junio for the pointer):
Lea Wiemann: Does anyone know off the top of their heads how git handles
character decoding errors in commands like git log? [...]
Junio 'gitster' Hamano: silently punt and show the original unmolested.
Junio 'gitster' Hamano: cf. pretty.c:pretty_print_commit()
So we're not guaranteed to be able to, in turn, decode git's output into
actual characters since it might just be byte soup.
Hence, how about this fallback strategy:
1. Decode according to the encoding header.
2. Decode as UTF-8 (passing through byte soup is often equivalent to
decoding UTF-8 since many terminals use UTF-8, and trying UTF-8 is
reasonably safe).
3. Decode as Latin1.
(Not that the fallbacks will matter a lot in practice, I think.)
> It is (much) better than forking git-cat-file for each commit shown
> on the list; nevertheless I think that it would be better to use git-log
> to generate list (or Git::Revlist) of Git::Commit objects. It is one
> fork less, but what more important you don't have to access repository
> twice for the very same objects.
You're confused; it's not one fork less, it's a write to a pipe less.
(Pleeeease look at the code before you write something. It's there, in
this very thread.) And I don't believe the "access the repository
twice" thing is anywhere near an actual issue. To summarize, you're
asking me to (a) write code and (presumably) (b) add something to the
interface of a public API, based on some (most probably faulty)
assumptions about performance? You should really read
<http://c2.com/cgi/wiki?PrematureOptimization>.
> if I understand correctly for log-like views you
> propose to first run simple git-rev-list [...], then feed list of
> revisions (perhaps via cache, i.e. excluding objects which are in
> cache) to 'git cat-file --batch' open two-directional pipeline.
Yup, it's an option, though currently it's a single cached call to git
log (or git rev-list).
> What I propose instead is to provide alternate method to fully
> instantiate Git::Commit object (in addition to ->_load), which would
> fill fields by parsing git-log / git-rev-list --headers output
Yes, but this would need a method in the API, it's not an optimization
that falls out for free. Cluttering an API for some obscure (= very
doubtful) optimization? Bad Idea.(tm)
> "git cat-file --batch" should have commits to be
> accessed in filesystem cache, which means in memory; but it is possible
> that they wouldn't be in cache because of I/O pressure
No. Page cache turnover time is at least around 10 seconds (and that's
under fairly artificial conditions), definitely not in the millisecond
range.
> I think that _not using_ Git::Cmd (or somesuch) API results in botched,
> horrible API
> our $git_version = $repo_root->repo(directory => 'dummy')->version;
> (Unless it is not needed any longer, or not used any longer; if it is
> so, then perhaps implementing Git::Cmd as generic wrapper around git
> commands, hiding for example ActivePerl hack, could be left for later).
It isn't used any longer -- I really suggest you read the whole thread
before replying. ;-)
>> As I wrote in my reply to Petr [...]
>
> Just a question: was this reply only to him, or to all?
To all, otherwise I wouldn't have Cc'ed the list.
>> I wouldn't -- see my blurb about error handling at the top of my reply
>> to Petr (<487BD0F3.2060508@gmail.com>). You're not supposed to pass
>> anything that you didn't get from get_sha1 into Git::Commit or
>> Git::Tag constructors, or your error handling is invariably broken.
>
> I can understand this simpler, although less than optimal, and geared
> mainly towards gitweb needs.
FTR, yes it is simpler, but no, it is not really geared toward gitweb
needs, and it's definitely not "less than optimal" in the sense of being
worse than the exception-based error handling Git.pm does. Trust on me
on this one. ;-)
> Errr... "yes" to first question means that 'reuse' option makes sense
> _only_ for get_bidi_pipe? If so, why it is present in other commands?
Yes, and no, it isn't present in other commands. (Hey, could you please
check the code before posting? Really.)
>>> Why name_rev, and no describe?
>> Feel free to add it. ;-) (It might take some work to come up with a
>> decent interface for that method.)
>
> Why do you _need_ name_rev, if you are not to include git-describe
> equivalent.
I needed it for gitweb. As I said, I'm not trying to create a complete
API. A describe_rev (or so) method can be added later, if and when it's
needed. (As I said, I don't think writing APIs without at least one use
case is a good idea anyway.)
>>> Should (for completeness) Git::Tag provide $tag->validate() method?
>
> I meant here equivalent of "git tag -v <tag>"
I guess it could be added. As with describe_rev, I won't add it myself,
in particular not as part of this patch series.
-- Lea
^ permalink raw reply
* [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Petr Baudis @ 2008-07-18 13:40 UTC (permalink / raw)
To: gitster; +Cc: git, Heikki Orsila
In-Reply-To: <20080718133644.GQ10151@machine.or.cz>
This patch rewrites the general description yet again, first clarifying
the high-level concept, mentioning the difference to remotes and using
the subtree merge strategy, then getting to the details about tree
entries and .gitmodules file.
The patch also makes few smallar grammar fixups within the rest of the
description and clarifies how does 'init' relate to 'update --init'.
Cc: Heikki Orsila <shdl@zakalwe.fi>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-submodule.txt | 68 ++++++++++++++++++++++++++-------------
1 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bb4e6fb..755142c 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -18,24 +18,43 @@ SYNOPSIS
DESCRIPTION
-----------
-Submodules are a special kind of tree entries which refer to a particular tree
-state in another repository. The tree entry describes
-the existence of a submodule with the given name and the exact revision that
-should be used, while an entry in `.gitmodules` file gives the location of
-the repository.
-
-When checked out, submodules will maintain their own independent repositories
-within their directories; the only link between the submodule and the "parent
-project" is the tree entry within the parent project mentioned above.
-
-This command will manage the tree entries and contents of the gitmodules file
-for you, as well as inspecting the status of your submodules and updating them.
-When adding a new submodule to the tree, the 'add' subcommand is to be used.
-However, when pulling a tree containing submodules, these will not be checked
-out by default; the 'init' and 'update' subcommands will maintain submodules
-checked out and at appropriate revision in your working tree. You can inspect
-the current status of your submodules using the 'submodule' subcommand and get
-an overview of changes 'update' would perform using the 'summary' subcommand.
+Submodules allow foreign repositories to be embedded within
+a dedicated subdirectory of the source tree, always pointed
+at a particular commit.
+
+They are not to be confused with remotes, which are meant mainly
+for branches of the same project; submodules are meant for
+different projects you would like to make part of your source tree,
+while the history of the two projects still stays completely
+independent and you cannot modify the contents of the submodule
+from within the main project.
+In case you want to merge the project histories, possibly make
+local modifications within the subtree, and considered the fact
+that all users will have to download and check out the subtree,
+you may choose to add a remote for the other project and use
+the 'subtree' merge strategy instead of setting up a submodule.
+
+Submodules are composed from a so-called `gitlink` tree entry
+in the main repository that refers to a particular commit object
+within the (completely separate) inner repository,
+and a record in the `.gitmodules` file at the root of the source
+tree, assigning a logical name to the submodule and describing
+the default URL the submodule shall be cloned from.
+The logical name can be used for overriding this URL within your
+local repository configuration (see 'submodule init').
+
+This command will manage the tree entries and contents of the
+gitmodules file for you, as well as inspect the status of your
+submodules and update them.
+When adding a new submodule to the tree, the 'add' subcommand
+is to be used. However, when pulling a tree containing submodules,
+these will not be checked out by default;
+the 'init' and 'update' subcommands will maintain submodules
+checked out and at appropriate revision in your working tree.
+You can briefly inspect the up-to-date status of your submodules
+using the 'status' subcommand and get a detailed overview of the
+difference between the index and checkouts using the 'summary'
+subcommand.
COMMANDS
@@ -78,10 +97,15 @@ status::
repository. This command is the default command for 'git-submodule'.
init::
- Initialize the submodules, i.e. register in .git/config each submodule
- name and url found in .gitmodules. The key used in .git/config is
- `submodule.$name.url`. This command does not alter existing information
- in .git/config.
+ Initialize the submodules, i.e. register each submodule name
+ and url found in .gitmodules into .git/config.
+ The key used in .git/config is `submodule.$name.url`.
+ This command does not alter existing information in .git/config.
+ You can then customize the submodule clone URLs in .git/config
+ for your local setup and proceed to 'git submodule update';
+ you can also just use 'git submodule update --init' without
+ the explicit 'init' step if you do not intend to customize
+ any submodule locations.
update::
Update the registered submodules, i.e. clone missing submodules and
^ permalink raw reply related
* [PATCH] Documentation: How to ignore local changes in tracked files
From: Petr Baudis @ 2008-07-18 14:11 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <20080717182619.GG10151@machine.or.cz>
This patch explains more carefully that `.gitignore` concerns only
untracked files and refers the reader to
git update-index --assume-unchanged
in the need of ignoring uncommitted changes in already tracked files.
The description of this option is lifted to a more "porcelainish"
level and explains the caveats of this usecase.
Whether feasible or not, I believe adding this functionality to
the porcelain is out of the scope of this patch. (And I personally
think that referring to the plumbing in the case of such a special
usage is fine.)
This is currently probably one of the top FAQs at #git and the
--assume-unchanged switch is not widely known; gitignore(5) is the first
place where people are likely to look for it.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-update-index.txt | 10 ++++++++++
Documentation/gitignore.txt | 11 ++++++++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index a91fd21..6b930bc 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -88,6 +88,16 @@ OPTIONS
sometimes helpful when working with a big project on a
filesystem that has very slow lstat(2) system call
(e.g. cifs).
++
+This option can be also used as a coarse file-level mechanism
+to ignore uncommitted changes in tracked files (akin to what
+`.gitignore` does for untracked files).
+You should remember that an explicit 'git add' operation will
+still cause the file to be refreshed from the working tree.
+Git will fail (gracefully) in case it needs to modify this file
+in the index e.g. when merging in a commit;
+thus, in case the assumed-untracked file is changed upstream,
+you will need to handle the situation manually.
-g::
--again::
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index fc0efd8..59321a2 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -13,9 +13,14 @@ DESCRIPTION
-----------
A `gitignore` file specifies intentionally untracked files that
-git should ignore. Each line in a `gitignore` file specifies a
-pattern.
-
+git should ignore.
+Note that all the `gitignore` files really concern only files
+that are not already tracked by git;
+in order to ignore uncommitted changes in already tracked files,
+please refer to the 'git update-index --assume-unchanged'
+documentation.
+
+Each line in a `gitignore` file specifies a pattern.
When deciding whether to ignore a path, git normally checks
`gitignore` patterns from multiple sources, with the following
order of precedence, from highest to lowest (within one level of
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox