* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 18:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Daniel Barkalow, Git ML
In-Reply-To: <20071106175627.GB9517@artemis.corp>
On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
> On the same vein, with today's next:
>
> $ git push origin :teaser
> To ssh://git.corp/srv/git/mmsx.git
> - [deleting] teaser
> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> Everything up-to-date
> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
I can't replicate this output; can you provide more information on your
test repo?
If it is related to the bug we have been discussing, there haven't been
any fixes applied yet. :)
-Peff
^ permalink raw reply
* Re: git pull opinion
From: Pascal Obry @ 2007-11-06 18:07 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
Aghiles a écrit :
> Hello,
>
> I am not sure this is the best place to write about this. Anyway,
> we just switched a couple of repositories to git (from svn) here
> at work and one thing people find annoying is a pull into
> a dirty directory. Before the "stash" feature it was even worse
> but now we can type:
>
> git stash
> git pull
> git stash apply
>
> But isn't that something we should be able to specify to the "pull"
> command ? Additionally and if I am not mistakn, those commands will
> create "dangling" commits and blobs. So one has to execute:
>
> git prune
>
> Is there an "easier" way to pull into a dirty directory ?
I'm using:
$ git config --global alias.update '!git stash && git pull && git stash
apply'
Then in a git repository just do:
$ git update
> ps; if someone is interested to hear what is the general opinion
> on switching to git from svn in our company, I could elaborate.
Would be nice to hear about that indeed.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711061230540.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> changes to <path>, relative to the index" (which would be the same as "git
> checkout <path>"), then committing that change just does not make sense.
>
> And it is this behaviour that people are seeking, not "git revert <commit>
> <path>".
Heh, I found this in the recent log somewhere.
<gitte> Really, I wonder how difficult git is for people who are not
brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
<gitte> From a user perspective, you might be correct. But then we have to
add 1000 commands to reflect the English language.
<gitte> Not what I want. [06:46]
I am wondering who said it ;-).
But anyway, I am inclined to agree that accepting "$scm revert
paths.." as a synonym for "git checkout -- paths..."
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-06 17:56 UTC (permalink / raw)
To: Nicolas Pitre, Daniel Barkalow, Jeff King, Git ML
In-Reply-To: <20071105175654.GD6205@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On the same vein, with today's next:
$ git push origin :teaser
To ssh://git.corp/srv/git/mmsx.git
- [deleting] teaser
refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
Everything up-to-date
fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-06 17:52 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Steffen Prohaska, Abdelrazak Younes, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711060857140.8577@ds9.cixit.se>
Peter Karlsson a écrit :
> I got errors almost right away when trying that (I need text mode to
> interface with some other programs), so Cygwin-git is a no-go for me at
Won't it be possible for you to have a specific mount point using
textmode and one with binmode ? This should allow you to have the best
of both world. Note that I've never done that so I don't know if it is
working fine.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Wincent Colaiuta @ 2007-11-06 17:43 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Junio C Hamano, Steven Grimm, git
In-Reply-To: <20071106124833.GA25637@artemis.corp>
El 6/11/2007, a las 13:48, Pierre Habouzit escribió:
> On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> In the same way, I would expect "git revert <commit> -- file" to
>>>>> undo the
>>>>> changes in that commit to _that_ file (something like "git merge-
>>>>> file
>>>>> file <commit>:file <commit>^:file"), but this time commit it,
>>>>> since it
>>>>> was committed at one stage.
>>>>
>>>> Allowing people to revert or cherry pick partially by using
>>>> paths limiter is a very good idea; ...
>>>
>>> As Pierre said earlier, a partial revert via "revert <commit> --
>>> <paths>" and a partial cherry-pick would make quite a lot of
>>> sense, and in addition, it should not be too hard to add.
>>
>> Yes, but Pierre also said earlier that people want to revert their
>> local
>> changes. And the logical thing to try that really is
>>
>> git revert <path>
>>
>> Now, if you read that out in English, it does not make too much
>> sense:
>> "revert the path" (not "revert the _changes_ to that file"). But
>> it is
>> what people try to do.
>>
>> However, IIUC another thing Pierre mentioned is that
>>
>> $scm revert <commit> <path>
>>
>> commonly means "revert the file _to the version_ stored in <commit>".
>> This is just different enough from "revert the _changes_ to that file
>> stored in <commit>" to bite people, no?
>
> Yeah but that's what checkout is for. The main source of iritation
> for
> new users comes (IMHO) from svn, where `svn revert path/to/file` is
> part
> of the workflow: in case of a conflict when you `svn up`, you have
> either to:
> (1) fix the conflict and `svn resolved path/to/file`
> (2) drop your changes and take the trunk version `svn revert path/
> to/file`
>
> People really expect git revert -- path/to/file to do the same as git
> checkout HEAD -- path/to/file. Though I believe that like I said,
> maybe
> we don't wan't git revert -- path/to/file to become the first class
> command to do that, but rather to do what the user meant, hinting
> him in
> the direction of the proper command. I wasn't really advocating that
> git-revert should be a complete implementation of what git checkout
> <comitish> -- <paths> does. YMMV.
I agree; they're semantically different and it wouldn't be a good
thing to start blurring the lines between them too much. It's just
unfortunate that the term "revert" is used by most other SCMs to mean
something different than what it means in "git-revert". I think the
best path here is education, what Pierre says, rather than changing
git-revert's semantics.
The other changes discussed so far in this thread (path-limiting git-
revert with preserving its semantics) seem like a good thing.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-06 17:08 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <1194367619.20020.9.camel@hinata.boston.redhat.com>
On 2007.11.06 11:46:59 -0500, Kristian Høgsberg wrote:
> On Tue, 2007-11-06 at 07:59 +0100, Björn Steinbrink wrote:
> ...
> > Note though, that Kristian had a similar check at the end of his email,
> > that included "only" (but lacked the bool conversion). The original
> > reason why I thought that it would be better was that for example
> > "git commit --all --only foo" didn't care about "only" at all. But that
> > actually was because the --all + paths usage check was broken. So the
> > fixed version actually refuses to use accept that, but with a (IMHO) not
> > so good error message:
> >
> > $ git commit -a -o file
> > Paths with -a does not make sense.
> >
> > Given that some people are used to just pass -a all the time, they might
> > just automatically pass it together with -o. And I think that we
> > actually want to tell them that -a + -o makes no sense instead. Just
> > like we do for -a + -i, which is kind of the complementary usage error.
> >
> > So I'd go for a correct version of Kristian's suggestion:
> >
> > if (!!also + !!only + !!all + !!interactive > 1)
> > die("Only one of --include/--only/--all/--interactive can be used.");
>
> Good points, I will use that in the next version of the patch. Just a
> note about the !! idiom (which I can't stand, fwiw): my version just
> added the variables, which were all integers, initialized to zero and
> incremented by the option parser when it sees the corresponding option.
> So what I had would work too, with the extra check that:
>
> $ git commit -a -a
>
> etc would give the error
>
> Only one of --include/--only/--all/--interactive can be used.
>
> which is acutally accurate.
Hm, why? The user used only one of them. The error message does not say
that you cannot pass the same one multiple times. And I don't think that
passing the same boolean flag twice should be treated as an usage error
either. There's no contradiction in wanting all files and, well, all
files to be committed.
Sidenote: The "or mask" stuff in the option parser would probably
prevent you from catching "-a -a" anyway, because the flag becomes truly
boolean ;-)
Björn
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Karl Hasselström @ 2007-11-06 16:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Alex Riesen, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711061550580.4362@racer.site>
On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> On Tue, 6 Nov 2007, Jeff King wrote:
>
> > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> >
> > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > the absence of patches. You could forget to save some patches,
> > > yes, but the presence of cur/ and new/ is no indicator for that.
> >
> > Read my message again. Alex is proposing ignoring errors in
> > opening the directories; I am proposing ignoring such errors
> > _only_ when the error is that the directory does not exist.
> >
> > IOW, if there is some other error in opening the directory, it
> > should be fatal, because you might be missing patches.
>
> Yeah, sorry, I missed that.
I think it might actually not be totally unreasonable to error out
unless both directories exist. From
http://www.qmail.org/qmail-manual-html/man5/maildir.html:
A directory in maildir format has three subdirectories, all on the
same filesystem: tmp, new, and cur.
In other words, if it doesn't have these three directories, it isn't a
Maildir directory.
On the other hand, one could argue that requiring both dirs to exist
is being too picky.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 16:58 UTC (permalink / raw)
To: Karl Hasselström
Cc: Jeff King, Alex Riesen, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <20071106163548.GA8207@diana.vm.bytemark.co.uk>
Hi,
On Tue, 6 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
>
> > On Tue, 6 Nov 2007, Jeff King wrote:
> >
> > > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > >
> > > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > > the absence of patches. You could forget to save some patches,
> > > > yes, but the presence of cur/ and new/ is no indicator for that.
> > >
> > > Read my message again. Alex is proposing ignoring errors in
> > > opening the directories; I am proposing ignoring such errors
> > > _only_ when the error is that the directory does not exist.
> > >
> > > IOW, if there is some other error in opening the directory, it
> > > should be fatal, because you might be missing patches.
> >
> > Yeah, sorry, I missed that.
>
> I think it might actually not be totally unreasonable to error out
> unless both directories exist. From
> http://www.qmail.org/qmail-manual-html/man5/maildir.html:
>
> A directory in maildir format has three subdirectories, all on the
> same filesystem: tmp, new, and cur.
>
> In other words, if it doesn't have these three directories, it isn't a
> Maildir directory.
>
> On the other hand, one could argue that requiring both dirs to exist
> is being too picky.
Not only that. The recent patch for OSX' mail program would be trivial
if we did not error out: the array would just contain cur, new and
Messages.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Kristian Høgsberg @ 2007-11-06 16:46 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20071106065941.GA6423@atjola.homenet>
On Tue, 2007-11-06 at 07:59 +0100, Björn Steinbrink wrote:
...
> Note though, that Kristian had a similar check at the end of his email,
> that included "only" (but lacked the bool conversion). The original
> reason why I thought that it would be better was that for example
> "git commit --all --only foo" didn't care about "only" at all. But that
> actually was because the --all + paths usage check was broken. So the
> fixed version actually refuses to use accept that, but with a (IMHO) not
> so good error message:
>
> $ git commit -a -o file
> Paths with -a does not make sense.
>
> Given that some people are used to just pass -a all the time, they might
> just automatically pass it together with -o. And I think that we
> actually want to tell them that -a + -o makes no sense instead. Just
> like we do for -a + -i, which is kind of the complementary usage error.
>
> So I'd go for a correct version of Kristian's suggestion:
>
> if (!!also + !!only + !!all + !!interactive > 1)
> die("Only one of --include/--only/--all/--interactive can be used.");
Good points, I will use that in the next version of the patch. Just a
note about the !! idiom (which I can't stand, fwiw): my version just
added the variables, which were all integers, initialized to zero and
incremented by the option parser when it sees the corresponding option.
So what I had would work too, with the extra check that:
$ git commit -a -a
etc would give the error
Only one of --include/--only/--all/--interactive can be used.
which is acutally accurate.
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Kristian Høgsberg @ 2007-11-06 16:42 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Björn Steinbrink, Junio C Hamano, git
In-Reply-To: <20071106091222.GE4435@artemis.corp>
On Tue, 2007-11-06 at 10:12 +0100, Pierre Habouzit wrote:
> On Mon, Nov 05, 2007 at 11:18:36PM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Mon, 5 Nov 2007, Bj?rn Steinbrink wrote:
> >
> > > On 2007.11.05 13:57:53 -0500, Kristian H?gsberg wrote:
> > >
> > > > The shell script just has
> > > >
> > > > case "$all,$interactive,$also,$#" in
> > > > *t,*t,*)
> > > > die "Cannot use -a, --interactive or -i at the same time." ;;
> > > >
> > > > which doesn't seem to care about the value of $also. As far as I
> > > > understand git commit, it doesn't make sense to pass any of -a, -i, -o
> > > > or --interactive at the same time so I guess I could join the checks
> > >
> > > Note that there are only two commas. The asterisks catch everything and
> > > $# won't be "t", so that catches anything with at least two t's.
> >
> > So shouldn't it be
> >
> > if (!!all + !!interactive + !!also > 1)
>
> Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
> macro we discussed, and the need for new option parsing callbacks
> arised, and I've created a:
>
> parse_opt_mask_{or,and,xor} commands that you declare this way:
>
> OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
> OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
> ...
That's useful here, and it should be useful in a lot of other places
using parse_options() where we end up or'ing flags into a mask based on
boolean options.
cheers,
Kristian
^ permalink raw reply
* Re: git pull opinion
From: Linus Torvalds @ 2007-11-06 16:36 UTC (permalink / raw)
To: Aghiles; +Cc: Bill Lear, Junio C Hamano, git
In-Reply-To: <3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com>
On Tue, 6 Nov 2007, Aghiles wrote:
>
> BitKeeper, for example, does a merge with a "dirty" directory.
> I am not saying that git should behave the same way but I think
> that this argument strengthens the point that it is not a
> "centralized repository" mindset.
Git does merge with a dirty directory too, but refuses to merge if it
needs to *change* any individual dirty *files*.
And that actually comes from one of the great strengths of git: in git
(unlike just about any other SCM out there) you can - and are indeed
expected to - resolve merges sanely in the working tree using normal
filesystem accesses (ie your basic normal editors and other tools).
That means that if there is a unresolved merge, you're actually expected
to edit things in the same place where they are dirty. Which means that
the merge logic doesn't want to mix up your dirty state and whatever
merged state, because that is then not sanely resolvable.
Now, I do think that we could relax the rule so that "files that are
modified must be clean in the working tree" could instead become "files
that actually don't merge _trivially_ must be clean in the working tree".
But basically, if it's not a trivial merge, then since it's done in the
working tree, the working tree has to be clean (or the merge would
overwrite it).
Doing a four-way merge is just going to confuse everybody.
So we *could* probably make unpack-trees.c: treeway_merge() allow this.
It's not totally trivial, because it requires that the CE_UPDATE be
replaced with something more ("CE_THREEWAY"): instead of just writing the
new result, it should do another three-way merge.
So it's within the range of possible, but it's actually pretty subtle. The
reason: we cannot (and *must*not*!) actually do the three-way merge early.
We need to do the full tree merge in stage 1, and then only if all files
are ok can we then check out the new tree. And we currently don't save the
merge information at all.
So to do this, we'd need to:
- remove the "verify_uptodate(old, o); invalidate_ce_path(old);" in
"merged_entry()", and actually *leave* the index with all three stages
intact, but set CE_UPDATE *and* return success.
- make check_updates() do the three-way merge of "original index, working
tree, new merged state" instead of just doing a "unlink_entry() +
checkout_entry()".
It doesn't actually look *hard*, but it's definitely subtle enough that
I'd be nervous about doing it. We're probably talking less than 50 lines
of actual diffs (this whole code uses good data structures, and we can
fairly easily represent the problem, and we already have the ability to do
a three-way merge!), but we're talking some really quite core code and
stuff that absolutely must not have any chance what-so-ever of ever
breaking!
To recap:
- it's probably a fairly simple change to just two well-defined places
(merge_entry() and check_updates())
- but dang, those two places are critical and absolutely must not be
screwed up, and while both of those functions are pretty simple, this
is some seriously core functionality.
If somebody wants to do it, I'll happily look over the result and test it
out, but it really needs to be really clean and obvious and rock solid.
And in the absense of that, I'll take the current safe code that just
says: don't confuse the merge and make it any more complex than it needs
to be.
Linus
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 15:51 UTC (permalink / raw)
To: Jeff King
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <20071106154740.GA24505@sigill.intra.peff.net>
Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
> On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
>
> > > > So? Why *STOP* reading the mails if just one of the directories could
> > > > not be opened? IOW, I suggest:
> > >
> > > Because you are then trying to apply a patch series with some patches
> > > potentially missing? Continuing only on errno == ENOENT seems prudent.
> >
> > I fail to see how the absence of one of cur/ or new/ can lead to the
> > absence of patches. You could forget to save some patches, yes, but the
> > presence of cur/ and new/ is no indicator for that.
>
> Read my message again. Alex is proposing ignoring errors in opening the
> directories; I am proposing ignoring such errors _only_ when the error
> is that the directory does not exist.
>
> IOW, if there is some other error in opening the directory, it should be
> fatal, because you might be missing patches.
Yeah, sorry, I missed that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Jeff King @ 2007-11-06 15:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711061100150.4362@racer.site>
On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > > So? Why *STOP* reading the mails if just one of the directories could
> > > not be opened? IOW, I suggest:
> >
> > Because you are then trying to apply a patch series with some patches
> > potentially missing? Continuing only on errno == ENOENT seems prudent.
>
> I fail to see how the absence of one of cur/ or new/ can lead to the
> absence of patches. You could forget to save some patches, yes, but the
> presence of cur/ and new/ is no indicator for that.
Read my message again. Alex is proposing ignoring errors in opening the
directories; I am proposing ignoring such errors _only_ when the error
is that the directory does not exist.
IOW, if there is some other error in opening the directory, it should be
fatal, because you might be missing patches.
-Peff
^ permalink raw reply
* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: Jon Loeliger @ 2007-11-06 15:01 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git
In-Reply-To: <ee77f5c20711051432w284cf22dx71192c145d25dced@mail.gmail.com>
David Symonds wrote:
> On 11/5/07, David Symonds <dsymonds@gmail.com> wrote:
>> [-s | --signoff] [<common diff options>]
>> - [--start-number <n>] [--numbered-files]
>> + [-n | --numbered-files | -N | --no-numbered]
>> + [--start-number <n>]
>
> Now that I look at it again, it seems the long options look quite
> inconsistent. I think it should be either
> --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> preference is with the latter (for brevity), but that breaks
> backward-compatibility.
>
> Would you accept a patch that changed --numbered-files to --numbered,
> and kept the former as a synonym?
There are two forms of numbered file output names:
the traditional "0001-Foo-the-bar" and just "1" styles.
Please don't break that. Both are needed.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] hooks--update: fix test for properly set up project description file
From: Andreas Ericsson @ 2007-11-06 13:55 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Junio C Hamano
In-Reply-To: <20071106134749.24233.qmail@809f27f669039a.315fe32.mid.smarden.org>
Gerrit Pape wrote:
> The update hook template intends to abort if the project description file
> hasn't been adjusted or is empty. This patch fixes the check for 'being
> adjusted'.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--update | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/templates/hooks--update b/templates/hooks--update
> index d8c7626..65e8c32 100644
> --- a/templates/hooks--update
> +++ b/templates/hooks--update
> @@ -34,8 +34,8 @@ fi
> allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
>
> # check for no description
> -projectdesc=$(sed -e '1p' "$GIT_DIR/description")
> -if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb" ]; then
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
Write this as
projectdesc=$(sed -e 1q "$GIT_DIR/description")
instead. It's a little shorter, a little faster and slightly more portable.
> +if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb." ]; then
> echo "*** Project description file hasn't been set" >&2
> exit 1
I must have missed when the default updatehook got this addendum, as it's
impossible to push to a repository that isn't named with this hook in
effect. I imagine this could lead to some fun problems when trying to
push to repositories on windows machines.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] contrib/hooks/post-receive-email: make subject prefix configurable
From: Gerrit Pape @ 2007-11-06 13:49 UTC (permalink / raw)
To: git, Junio C Hamano
Email subjects are prefixed with "[SCM] " by default, make this optionally
configurable through the hooks.emailprefix config option.
Suggested by martin f krafft through
http://bugs.debian.org/428418
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 9b9a977..3904c18 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -35,10 +35,12 @@
# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope
# sender address to be set
+# hooks.emailprefix
+# All emails have their subjects prefixed with this prefix, or "[SCM]"
+# if emailprefix is unset, to aid filtering
#
# Notes
# -----
-# All emails have their subjects prefixed with "[SCM]" to aid filtering.
# All emails include the headers "X-Git-Refname", "X-Git-Oldrev",
# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and
# give information for debugging.
@@ -188,7 +190,7 @@ generate_email_header()
# Generate header
cat <<-EOF
To: $recipients
- Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
+ Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
@@ -604,7 +606,6 @@ send_mail()
# ---------------------------- main()
# --- Constants
-EMAILPREFIX="[SCM] "
LOGBEGIN="- Log -----------------------------------------------------------------"
LOGEND="-----------------------------------------------------------------------"
@@ -628,6 +629,7 @@ fi
recipients=$(git repo-config hooks.mailinglist)
announcerecipients=$(git repo-config hooks.announcelist)
envelopesender=$(git-repo-config hooks.envelopesender)
+emailprefix=$(git-repo-config hooks.emailprefix || echo '[SCM] ')
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.5.3.5
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: reformat to wrap comments at 76 chars
From: Gerrit Pape @ 2007-11-06 13:48 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 199 ++++++++++++++++++++------------------
1 files changed, 107 insertions(+), 92 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 379cedc..9b9a977 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -2,24 +2,26 @@
#
# Copyright (c) 2007 Andy Parkins
#
-# An example hook script to mail out commit update information. This hook sends emails
-# listing new revisions to the repository introduced by the change being reported. The
-# rule is that (for branch updates) each commit will appear on one email and one email
-# only.
+# An example hook script to mail out commit update information. This hook
+# sends emails listing new revisions to the repository introduced by the
+# change being reported. The rule is that (for branch updates) each commit
+# will appear on one email and one email only.
#
-# This hook is stored in the contrib/hooks directory. Your distribution will have put
-# this somewhere standard. You should make this script executable then link to it in
-# the repository you would like to use it in. For example, on debian the hook is stored
-# in /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# This hook is stored in the contrib/hooks directory. Your distribution
+# will have put this somewhere standard. You should make this script
+# executable then link to it in the repository you would like to use it in.
+# For example, on debian the hook is stored in
+# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
-# This hook script assumes it is enabled on the central repository of a project, with
-# all users pushing only to it and not between each other. It will still work if you
-# don't operate in that style, but it would become possible for the email to be from
-# someone other than the person doing the push.
+# This hook script assumes it is enabled on the central repository of a
+# project, with all users pushing only to it and not between each other. It
+# will still work if you don't operate in that style, but it would become
+# possible for the email to be from someone other than the person doing the
+# push.
#
# Config
# ------
@@ -28,11 +30,11 @@
# emails for every ref update.
# hooks.announcelist
# This is the list that all pushes of annotated tags will go to. Leave it
-# blank to default to the mailinglist field. The announce emails lists the
-# short log summary of the changes since the last annotated tag.
+# blank to default to the mailinglist field. The announce emails lists
+# the short log summary of the changes since the last annotated tag.
# hooks.envelopesender
-# If set then the -f option is passed to sendmail to allow the envelope sender
-# address to be set
+# If set then the -f option is passed to sendmail to allow the envelope
+# sender address to be set
#
# Notes
# -----
@@ -49,8 +51,8 @@
# this is and calls the appropriate body-generation routine after outputting
# the common header
#
-# Note this function doesn't actually generate any email output, that is taken
-# care of by the functions it calls:
+# Note this function doesn't actually generate any email output, that is
+# taken care of by the functions it calls:
# - generate_email_header
# - generate_create_XXXX_email
# - generate_update_XXXX_email
@@ -225,8 +227,9 @@ generate_create_branch_email()
echo $LOGBEGIN
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
- # ref that were previously not accessible (see generate_update_branch_email
- # for the explanation of this command)
+ # ref that were previously not accessible
+ # (see generate_update_branch_email for the explanation of this
+ # command)
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $newrev
echo $LOGEND
@@ -254,9 +257,10 @@ generate_update_branch_email()
#
# git-rev-list N ^O ^X ^N
#
- # So, we need to build up the list more carefully. git-rev-parse will
- # generate a list of revs that may be fed into git-rev-list. We can get
- # it to make the "--not --all" part and then filter out the "^N" with:
+ # So, we need to build up the list more carefully. git-rev-parse
+ # will generate a list of revs that may be fed into git-rev-list.
+ # We can get it to make the "--not --all" part and then filter out
+ # the "^N" with:
#
# git-rev-parse --not --all | grep -v N
#
@@ -266,16 +270,17 @@ generate_update_branch_email()
# git-rev-list N ^O ^X
#
# This leaves a problem when someone else updates the repository
- # while this script is running. Their new value of the ref we're working
- # on would be included in the "--not --all" output; and as our $newrev
- # would be an ancestor of that commit, it would exclude all of our
- # commits. What we really want is to exclude the current value of
- # $refname from the --not list, rather than N itself. So:
+ # while this script is running. Their new value of the ref we're
+ # working on would be included in the "--not --all" output; and as
+ # our $newrev would be an ancestor of that commit, it would exclude
+ # all of our commits. What we really want is to exclude the current
+ # value of $refname from the --not list, rather than N itself. So:
#
# git-rev-parse --not --all | grep -v $(git-rev-parse $refname)
#
- # Get's us to something pretty safe (apart from the small time between
- # refname being read, and git-rev-parse running - for that, I give up)
+ # Get's us to something pretty safe (apart from the small time
+ # between refname being read, and git-rev-parse running - for that,
+ # I give up)
#
#
# Next problem, consider this:
@@ -283,18 +288,18 @@ generate_update_branch_email()
# \
# * --- X --- * --- N ($newrev)
#
- # That is to say, there is no guarantee that oldrev is a strict subset of
- # newrev (it would have required a --force, but that's allowed). So, we
- # can't simply say rev-list $oldrev..$newrev. Instead we find the common
- # base of the two revs and list from there.
+ # That is to say, there is no guarantee that oldrev is a strict
+ # subset of newrev (it would have required a --force, but that's
+ # allowed). So, we can't simply say rev-list $oldrev..$newrev.
+ # Instead we find the common base of the two revs and list from
+ # there.
#
- # As above, we need to take into account the presence of X; if another
- # branch is already in the repository and points at some of the revisions
- # that we are about to output - we don't want them. The solution is as
- # before: git-rev-parse output filtered.
+ # As above, we need to take into account the presence of X; if
+ # another branch is already in the repository and points at some of
+ # the revisions that we are about to output - we don't want them.
+ # The solution is as before: git-rev-parse output filtered.
#
- # Finally, tags:
- # 1 --- 2 --- O --- T --- 3 --- 4 --- N
+ # Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N
#
# Tags pushed into the repository generate nice shortlog emails that
# summarise the commits between them and the previous tag. However,
@@ -302,13 +307,14 @@ generate_update_branch_email()
# for a branch update. Therefore we still want to output revisions
# that have been output on a tag email.
#
- # Luckily, git-rev-parse includes just the tool. Instead of using "--all"
- # we use "--branches"; this has the added benefit that "remotes/" will
- # be ignored as well.
-
- # List all of the revisions that were removed by this update, in a fast forward
- # update, this list will be empty, because rev-list O ^N is empty. For a non
- # fast forward, O ^N is the list of removed revisions
+ # Luckily, git-rev-parse includes just the tool. Instead of using
+ # "--all" we use "--branches"; this has the added benefit that
+ # "remotes/" will be ignored as well.
+
+ # List all of the revisions that were removed by this update, in a
+ # fast forward update, this list will be empty, because rev-list O
+ # ^N is empty. For a non fast forward, O ^N is the list of removed
+ # revisions
fast_forward=""
rev=""
for rev in $(git rev-list $newrev..$oldrev)
@@ -321,10 +327,10 @@ generate_update_branch_email()
fi
# List all the revisions from baserev to newrev in a kind of
- # "table-of-contents"; note this list can include revisions that have
- # already had notification emails and is present to show the full detail
- # of the change from rolling back the old revision to the base revision and
- # then forward to the new revision
+ # "table-of-contents"; note this list can include revisions that
+ # have already had notification emails and is present to show the
+ # full detail of the change from rolling back the old revision to
+ # the base revision and then forward to the new revision
for rev in $(git rev-list $oldrev..$newrev)
do
revtype=$(git cat-file -t "$rev")
@@ -334,19 +340,20 @@ generate_update_branch_email()
if [ "$fast_forward" ]; then
echo " from $oldrev ($oldrev_type)"
else
- # 1. Existing revisions were removed. In this case newrev is a
- # subset of oldrev - this is the reverse of a fast-forward,
- # a rewind
- # 2. New revisions were added on top of an old revision, this is
- # a rewind and addition.
+ # 1. Existing revisions were removed. In this case newrev
+ # is a subset of oldrev - this is the reverse of a
+ # fast-forward, a rewind
+ # 2. New revisions were added on top of an old revision,
+ # this is a rewind and addition.
- # (1) certainly happened, (2) possibly. When (2) hasn't happened,
- # we set a flag to indicate that no log printout is required.
+ # (1) certainly happened, (2) possibly. When (2) hasn't
+ # happened, we set a flag to indicate that no log printout
+ # is required.
echo ""
- # Find the common ancestor of the old and new revisions and compare
- # it with newrev
+ # Find the common ancestor of the old and new revisions and
+ # compare it with newrev
baserev=$(git merge-base $oldrev $newrev)
rewind_only=""
if [ "$baserev" = "$newrev" ]; then
@@ -387,21 +394,22 @@ generate_update_branch_email()
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $oldrev..$newrev
- # XXX: Need a way of detecting whether git rev-list actually outputted
- # anything, so that we can issue a "no new revisions added by this
- # update" message
+ # XXX: Need a way of detecting whether git rev-list actually
+ # outputted anything, so that we can issue a "no new
+ # revisions added by this update" message
echo $LOGEND
else
echo "No new revisions were added by this update."
fi
- # The diffstat is shown from the old revision to the new revision. This
- # is to show the truth of what happened in this change. There's no point
- # showing the stat from the base to the new revision because the base
- # is effectively a random revision at this point - the user will be
- # interested in what this revision changed - including the undoing of
- # previous revisions in the case of non-fast forward updates.
+ # The diffstat is shown from the old revision to the new revision.
+ # This is to show the truth of what happened in this change.
+ # There's no point showing the stat from the base to the new
+ # revision because the base is effectively a random revision at this
+ # point - the user will be interested in what this revision changed
+ # - including the undoing of previous revisions in the case of
+ # non-fast forward updates.
echo ""
echo "Summary of changes:"
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
@@ -448,7 +456,8 @@ generate_update_atag_email()
#
generate_atag_email()
{
- # Use git-for-each-ref to pull out the individual fields from the tag
+ # Use git-for-each-ref to pull out the individual fields from the
+ # tag
eval $(git for-each-ref --shell --format='
tagobject=%(*objectname)
tagtype=%(*objecttype)
@@ -459,8 +468,10 @@ generate_atag_email()
echo " tagging $tagobject ($tagtype)"
case "$tagtype" in
commit)
+
# If the tagged object is a commit, then we assume this is a
- # release, and so we calculate which tag this tag is replacing
+ # release, and so we calculate which tag this tag is
+ # replacing
prevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)
if [ -n "$prevtag" ]; then
@@ -477,25 +488,27 @@ generate_atag_email()
echo ""
echo $LOGBEGIN
- # Show the content of the tag message; this might contain a change log
- # or release notes so is worth displaying.
+ # Show the content of the tag message; this might contain a change
+ # log or release notes so is worth displaying.
git cat-file tag $newrev | sed -e '1,/^$/d'
echo ""
case "$tagtype" in
commit)
- # Only commit tags make sense to have rev-list operations performed
- # on them
+ # Only commit tags make sense to have rev-list operations
+ # performed on them
if [ -n "$prevtag" ]; then
# Show changes since the previous release
git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
else
- # No previous tag, show all the changes since time began
+ # No previous tag, show all the changes since time
+ # began
git rev-list --pretty=short $newrev | git shortlog
fi
;;
*)
- # XXX: Is there anything useful we can do for non-commit objects?
+ # XXX: Is there anything useful we can do for non-commit
+ # objects?
;;
esac
@@ -544,13 +557,14 @@ generate_update_general_email()
#
generate_general_email()
{
- # Unannotated tags are more about marking a point than releasing a version;
- # therefore we don't do the shortlog summary that we do for annotated tags
- # above - we simply show that the point has been marked, and print the log
- # message for the marked point for reference purposes
+ # Unannotated tags are more about marking a point than releasing a
+ # version; therefore we don't do the shortlog summary that we do for
+ # annotated tags above - we simply show that the point has been
+ # marked, and print the log message for the marked point for
+ # reference purposes
#
- # Note this section also catches any other reference type (although there
- # aren't any) and deals with them in the same way.
+ # Note this section also catches any other reference type (although
+ # there aren't any) and deals with them in the same way.
echo ""
if [ "$newrev_type" = "commit" ]; then
@@ -558,10 +572,10 @@ generate_general_email()
git show --no-color --root -s $newrev
echo $LOGEND
else
- # What can we do here? The tag marks an object that is not a commit,
- # so there is no log for us to display. It's probably not wise to
- # output git-cat-file as it could be a binary blob. We'll just say how
- # big it is
+ # What can we do here? The tag marks an object that is not
+ # a commit, so there is no log for us to display. It's
+ # probably not wise to output git-cat-file as it could be a
+ # binary blob. We'll just say how big it is
echo "$newrev is a $newrev_type, and is $(git cat-file -s $newrev) bytes long."
fi
}
@@ -604,8 +618,8 @@ if [ -z "$GIT_DIR" ]; then
fi
projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
-# Check if the description is unchanged from it's default, and shorten it to a
-# more manageable length if it is
+# Check if the description is unchanged from it's default, and shorten it to
+# a more manageable length if it is
if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
then
projectdesc="UNNAMED PROJECT"
@@ -616,11 +630,12 @@ announcerecipients=$(git repo-config hooks.announcelist)
envelopesender=$(git-repo-config hooks.envelopesender)
# --- Main loop
-# Allow dual mode: run from the command line just like the update hook, or if
-# no arguments are given then run as a hook script
+# Allow dual mode: run from the command line just like the update hook, or
+# if no arguments are given then run as a hook script
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
# Output to the terminal in command line mode - if someone wanted to
- # resend an email; they could redirect the output to sendmail themselves
+ # resend an email; they could redirect the output to sendmail
+ # themselves
PAGER= generate_email $2 $3 $1
else
while read oldrev newrev refname
--
1.5.3.5
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: fix typo
From: Gerrit Pape @ 2007-11-06 13:48 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2aa9bb5..379cedc 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -30,7 +30,7 @@
# This is the list that all pushes of annotated tags will go to. Leave it
# blank to default to the mailinglist field. The announce emails lists the
# short log summary of the changes since the last annotated tag.
-# hook.envelopesender
+# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope sender
# address to be set
#
--
1.5.3.5
^ permalink raw reply related
* [PATCH] hooks--update: fix test for properly set up project description file
From: Gerrit Pape @ 2007-11-06 13:47 UTC (permalink / raw)
To: git, Junio C Hamano
The update hook template intends to abort if the project description file
hasn't been adjusted or is empty. This patch fixes the check for 'being
adjusted'.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
templates/hooks--update | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index d8c7626..65e8c32 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -34,8 +34,8 @@ fi
allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
# check for no description
-projectdesc=$(sed -e '1p' "$GIT_DIR/description")
-if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb" ]; then
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
+if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb." ]; then
echo "*** Project description file hasn't been set" >&2
exit 1
fi
--
1.5.3.5
^ permalink raw reply related
* Re: git-merge ignore specific files
From: Jakub Narebski @ 2007-11-06 13:46 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <323303.75335.qm@web55010.mail.re4.yahoo.com>
Bill Priest wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Bill Priest wrote:
>>
>>> All,
>>> I have two branches that are slightly different and
>>> most changes "belong" in both. There are a handful of
>>> files/directories that are disparate. Is there any
>>> way in git to tell it not to merge these files? Kind
>>> of like .gitignore but for merges.
>>
>> Most probably you can use gitattributes for that.
>> Or you can use 'our' merge strategy.
>
> Can you point me to some docs on "our" merge strategy?
git-merge(1), section "Merge strategies":
ours::
This resolves any number of heads, but the result of the
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
>>> In addition I'd like a way to specify to git-merge
>>> to leave all merged files unrecorded in the index.
>>> Then as I go through each file making sure that the
>>> merge "makes sense" (not that git did the right thing;
>>> but that I want the changes in both branches) that
>>> I add the change to the index.
>>
>> You can use gitattributes for that.
>
> I did man gitattributes and nothing jumped out at me
> as far as an attribute that I could set/unset that
> would stop a file from being merged. What am I
> missing?
See `diff' and `merge' attributes, for example
*.nbi -diff -merge
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-merge ignore specific files
From: Bill Priest @ 2007-11-06 13:15 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <fgpong$fmn$1@ger.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Bill Priest wrote:
>
> > All,
> > I have two branches that are slightly different
> and
> > most changes "belong" in both. There are a
> handful of
> > files/directories that are disparate. Is there
> any
> > way in git to tell it not to merge these files?
> Kind
> > of like .gitignore but for merges.
>
> Most probably you can use gitattributes for that.
> Or you can use 'our' merge strategy.
Can you point me to some docs on "our" merge strategy?
>
> > In addition I'd like a way to specify to
> git-merge
> > to leave all merged files unrecorded in the index.
>
> > Then as I go through each file making sure that
> the
> > merge "makes sense" (not that git did the right
> thing;
> > but that I want the changes in both branches) that
> I
> > add the change to the index.
>
> You can use gitattributes for that.
I did man gitattributes and nothing jumped out at me
as far as an attribute that I could set/unset that
would stop a file from being merged. What am I
missing?
Bill
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git-merge ignore specific files
From: Jakub Narebski @ 2007-11-06 13:03 UTC (permalink / raw)
To: git
In-Reply-To: <174134.11501.qm@web55007.mail.re4.yahoo.com>
Bill Priest wrote:
> All,
> I have two branches that are slightly different and
> most changes "belong" in both. There are a handful of
> files/directories that are disparate. Is there any
> way in git to tell it not to merge these files? Kind
> of like .gitignore but for merges.
Most probably you can use gitattributes for that.
Or you can use 'our' merge strategy.
> In addition I'd like a way to specify to git-merge
> to leave all merged files unrecorded in the index.
> Then as I go through each file making sure that the
> merge "makes sense" (not that git did the right thing;
> but that I want the changes in both branches) that I
> add the change to the index.
You can use gitattributes for that.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-merge ignore specific files
From: Andreas Ericsson @ 2007-11-06 12:53 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <174134.11501.qm@web55007.mail.re4.yahoo.com>
Bill Priest wrote:
> All,
> I have two branches that are slightly different and
> most changes "belong" in both. There are a handful of
> files/directories that are disparate. Is there any
> way in git to tell it not to merge these files? Kind
> of like .gitignore but for merges.
> In addition I'd like a way to specify to git-merge
> to leave all merged files unrecorded in the index.
> Then as I go through each file making sure that the
> merge "makes sense" (not that git did the right thing;
> but that I want the changes in both branches) that I
> add the change to the index.
> I'm sure that I'm probably using git "incorrectly"
> and I welcome suggestions for modifying my workflow to
> a git style.
>
> Any and all suggestions greatly appreciated,
>
At a cursory glance at the sources, it looks as if you should be able to
get what you want with pretty small modifications to builtin-read-tree.c
and git-merge.sh.
Specifically, 'git read-tree' (which does the heavy lifting during merges)
takes --exclude-per-directory as an argument. You want to teach 'git merge'
to do the same and pass that argument along to 'git read-tree'. Then it's
just a matter of maintaining two sets of .gitignore files, one of which
you'd probably want to call .mergeignore (or something) and make sure you
don't forget to pass that option when you merge (although I assume you'd
notice if you'd forgotten it during conflict resolution).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 12:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711061216330.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > >> In the same way, I would expect "git revert <commit> -- file" to undo the
> > >> changes in that commit to _that_ file (something like "git merge-file
> > >> file <commit>:file <commit>^:file"), but this time commit it, since it
> > >> was committed at one stage.
> > >
> > > Allowing people to revert or cherry pick partially by using
> > > paths limiter is a very good idea; ...
> >
> > As Pierre said earlier, a partial revert via "revert <commit> --
> > <paths>" and a partial cherry-pick would make quite a lot of
> > sense, and in addition, it should not be too hard to add.
>
> Yes, but Pierre also said earlier that people want to revert their local
> changes. And the logical thing to try that really is
>
> git revert <path>
>
> Now, if you read that out in English, it does not make too much sense:
> "revert the path" (not "revert the _changes_ to that file"). But it is
> what people try to do.
>
> However, IIUC another thing Pierre mentioned is that
>
> $scm revert <commit> <path>
>
> commonly means "revert the file _to the version_ stored in <commit>".
> This is just different enough from "revert the _changes_ to that file
> stored in <commit>" to bite people, no?
Yeah but that's what checkout is for. The main source of iritation for
new users comes (IMHO) from svn, where `svn revert path/to/file` is part
of the workflow: in case of a conflict when you `svn up`, you have
either to:
(1) fix the conflict and `svn resolved path/to/file`
(2) drop your changes and take the trunk version `svn revert path/to/file`
People really expect git revert -- path/to/file to do the same as git
checkout HEAD -- path/to/file. Though I believe that like I said, maybe
we don't wan't git revert -- path/to/file to become the first class
command to do that, but rather to do what the user meant, hinting him in
the direction of the proper command. I wasn't really advocating that
git-revert should be a complete implementation of what git checkout
<comitish> -- <paths> does. YMMV.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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