* Re: [PATCH] Replace the cryptic messages from "git stash show".
From: Jing Xue @ 2007-12-15 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63z0o59r.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 14, 2007 at 10:12:32PM -0800, Junio C Hamano wrote:
>
> Is it just me who feels that the added code is much worse than the
> disease?
I wouldn't be surprised. Shell scripting is by no means my long suit -
in fact, I am not even sure it's "a suit" of mine at all. I didn't like
what I saw and basically had two options:
1. Send a "this is not user friendly" rant and get beaten up by "why
don't you even try?"
2. Try and hack together something, submit it, and keep fixing it until
it makes it - and learn something in the process, maybe at the price of
being mocked at, but I don't care.
In particular, as far as I _could_ see, there are probably at least one
place I'm doing something potentially absurd, but couldn't figure out
anything better:
I'm not sure how to test if there is a stash name specified, so I
tried:
test "$flags" = "$@"
but then it breaks when $@ has a space in it. Hence the pointless
assignment to $arguments first.
The reason I removed the --default option to rev-parse is that it
doesn't distinguish between no stash name or an invalid one.
I'm sure there are other things people don't like - some because my
shell scripting sucks, some others maybe because of style differences.
At any rate, I'm open to criticism. So bring it on. 8-)
--
Jing Xue
^ permalink raw reply
* Re: [RFC 1/4] Add diff-diff, which compares the diffs of two commits
From: Steffen Prohaska @ 2007-12-15 17:33 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071215170436.GA22485@atjola.homenet>
On Dec 15, 2007, at 6:04 PM, Björn Steinbrink wrote:
> On 2007.12.15 17:51:42 +0100, Steffen Prohaska wrote:
>> The following patch series adds experimental diff-diff support.
> [...]
>> At this point, I'm only seeking comments about the general direction.
>> The patches should not be applied to git.git.
>>
>> - Are similar approaches already available?
>
> interdiff from patchutils. Probably interdiff would also be a better
> name than diff-diff, just to be consistent with what is already there.
> And using interdiff instead of plain diff in your script might also
> yield better results (I didn't use interdiff that often yet).
At a first glance, interdiff yields more intuitive results if it
works, but it may fail if the two patches differ to much. I need
to play more to see how useful it is in real world examples. I
did not know interdiff before.
At this point I'm not convinced that interdiff is exactly what I
have in mind. For example it doesn't show differences between
commit messages of two git patches.
Steffen
^ permalink raw reply
* Re: trim_common_tail bug?
From: Junio C Hamano @ 2007-12-15 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, git
In-Reply-To: <20071215155150.GA24810@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 700def2..eb60e88 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -124,6 +124,8 @@ static void trim_common_tail(mmfile_t *a, mmfile_t *b, long ctx)
> for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
> while (recovered < trimmed && ap[recovered] != '\n')
> recovered++;
> + if (recovered < trimmed && ap[recovered] == '\n')
> + recovered++;
> }
> a->size -= (trimmed - recovered);
> b->size -= (trimmed - recovered);
Shoot. Thanks for spotting.
Wouldn't it be enough to do:
for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
while (recovered < trimmed && ap[recovered++] != '\n')
; /* nothing */
}
then (warning: I haven't had my coffee yet)?
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Michael Dressel @ 2007-12-15 18:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071214074925.GA3525@steel.home>
On Fri, 14 Dec 2007, Alex Riesen wrote:
> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
>> On Thu, 13 Dec 2007, Alex Riesen wrote:
>>> On 13/12/2007, Michael Dressel wrote:
>>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>>> that is because git was able to do a fast forward?
>>>
>>> Yes. Because fast-forward is what it called: fast-forward.
>>> It does not do any commits at all.
>>>
>>
>> It looks like I misunderstood the meaning of --no-commit. I have to use
>> --squash in this case.
>>
>
> Maybe. Or maybe you misunderstood the meaning of --squash, which also
> is not a merge.
Since "git merge --squash <branch>" does a merge of <branch> into the
working tree why would you not call it a merge?
Anyway that was what I wanted. Merging <branch> (a topic branch) into my
current branch (the main branch) but being able to create commits that are
more suitable for keeping in the history of the current branch than the
commits I created during developing on <branch>.
Would you recommend a different way of doing this?
Thank you,
Michael
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Björn Steinbrink @ 2007-12-15 18:26 UTC (permalink / raw)
To: Michael Dressel; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos>
On 2007.12.15 19:14:48 +0100, Michael Dressel wrote:
>
>
> On Fri, 14 Dec 2007, Alex Riesen wrote:
>
>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
>>> On Thu, 13 Dec 2007, Alex Riesen wrote:
>>>> On 13/12/2007, Michael Dressel wrote:
>>>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>>>> that is because git was able to do a fast forward?
>>>>
>>>> Yes. Because fast-forward is what it called: fast-forward.
>>>> It does not do any commits at all.
>>>>
>>>
>>> It looks like I misunderstood the meaning of --no-commit. I have to use
>>> --squash in this case.
>>>
>>
>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>> is not a merge.
>
> Since "git merge --squash <branch>" does a merge of <branch> into the
> working tree why would you not call it a merge?
A "real" merge commit has at least two parents, and retains the
individual commits of each branch in the history. It just connects two
lines of history. --squash just takes all changes and produces a
single-parented commit, destroying the individual commits that
originally introduced the changes.
> Anyway that was what I wanted. Merging <branch> (a topic branch) into my
> current branch (the main branch) but being able to create commits that are
> more suitable for keeping in the history of the current branch than the
> commits I created during developing on <branch>.
> Would you recommend a different way of doing this?
If you didn't publish your topic branch, use interactive rebasing to
re-order/edit your commits.
Björn
^ permalink raw reply
* Re: [PATCH 0/3 (resend)] gitweb: Miscelanous fixes
From: Junio C Hamano @ 2007-12-15 19:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200712151534.50951.jnareb@gmail.com>
Thanks for a reminder. Will look at it but I'll be offline for several
hours today.
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Jakub Narebski @ 2007-12-15 19:18 UTC (permalink / raw)
To: Michael Dressel; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos>
Michael Dressel <MichaelTiloDressel@t-online.de> writes:
> On Fri, 14 Dec 2007, Alex Riesen wrote:
>
>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
>>> On Thu, 13 Dec 2007, Alex Riesen wrote:
>>>> On 13/12/2007, Michael Dressel wrote:
>>>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>>>> that is because git was able to do a fast forward?
>>>>
>>>> Yes. Because fast-forward is what it called: fast-forward.
>>>> It does not do any commits at all.
>>>>
>>>
>>> It looks like I misunderstood the meaning of --no-commit. I have to use
>>> --squash in this case.
>>>
>>
>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>> is not a merge.
>
> Since "git merge --squash <branch>" does a merge of <branch> into the
> working tree why would you not call it a merge?
A few illustrations. Commits A, B, C were made on 'trunk', commits
a, b, c were made on 'branch'. You are on 'trunk', running
"git merge <options> branch". We assume that there are no conflicts.
1. A non fast-forward case
1---2---3---A---B---C <-- trunk <-- HEAD
\
\-a---b---c <-- branch
1.1. "git merge branch"
1---2---3---A---B---C--M <-- trunk <-- HEAD
\ /
\-a---b---c/ <-- branch
M is _merge_ commits, with two parents: C and c. It was created
by "git merge branch".
1.2. "git merge --no-commit branch"
/-------- trunk <-- HEAD
v
1---2---3---A---B---C--*
\ /
\-a---b---c/ <-- branch
^
\-------- MERGE_HEAD
The merge commit '*' is prepared, but not yet committed, just
as if there were merge conflict during merge. "git commit"
would commit a merge (and would tell you that it does a merge
commit).
1.3. "git merge --no-commit --no-ff branch"
Like in 1.2, because it is non fast-forward case.
1.4. "git merge --squash branch"
1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD
\
\-a---b---c <-- branch
"[abc]'" is a _single parent_ commit (it is not a merge commit!)
which incorporates changes made on branch as if it were made in
a single, large (!) commit.
1.5. "git rebase trunk branch" (or "git pull --rebase branch")
1---2---3---A---B---C <-- trunk
\
\-a'--b'--c' <-- branch <-- HEAD
Rebase is step-by-step process, replying commits a, b, c on top
of trunk, trying for the same _changes_. a', b', c' are newly
created commits, introducing the same changes as a, b, c if there
were no rebase conflicts.
I think that "git pull --rebase branch" goes a step further and
actually does after-rebase fast-forward merge, and does not change
branch, but I might be mistaken.
1---2---3---A---B---C---a'--b'--c' <-- trunk <-- HEAD
\
\-a---b---c <-- branch
2. Fast forward case; there are no commits A, B, C, and we
start from the following situation:
1---2---3 <-- trunk <-- HEAD
\
\-a---b---c <-- branch
2.1. "git merge branch"
1---2---3 /----- trunk <-- HEAD
\ v
\-a---b---c <-- branch
Fast forward results in simply moving the head of trunk.
It does not create a commit, hence:
2.2. "git merge --no-commit branch"
Like in 2.1, because fast-forwarding does not create a commit.
2.3. "git merge --no-commit --no-ff branch"
1---2---3 <-- trunk <-- HEAD
\
\-a---b---c <-- branch
(probably with some error message).
Test of understanding the concepts: what does
"git merge --squash --no-commit" does?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-browse-help?
From: Junio C Hamano @ 2007-12-15 19:25 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Christian Couder, git
In-Reply-To: <20071215111154.GB3447@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, Junio, I remember discussion a long time ago about doing:
>
> cover letter
> -- >8 --
> commit
> ---
> diff
>
> versus
>
> commit
> ---
> cover letter
> diff
>
> and I recall that you did not have a strong preference. I have started
> using the former, as I find it a bit more convenient to write (and I
> think it is more readable when you are following up a discussion rather
> than writing a real cover letter or commenting on the patch).
Yeah, and it is not too inconvenient to trim it off if you use "am -i"
or "commit --amend". An added bonus is unlike the "top-post" style, the
cover material is available when editing the final log message, so I
actually slightly prefer "cover -- >8 -- log --- patch" myself.
^ permalink raw reply
* Re: git-browse-help?
From: Junio C Hamano @ 2007-12-15 19:26 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Christian Couder, git
In-Reply-To: <20071215110153.GA3447@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Although I would have called it "git-help--browse" rather than
> "git-browse--help" since
Good point.
^ permalink raw reply
* Re: [RFC 1/4] Add diff-diff, which compares the diffs of two commits
From: Junio C Hamano @ 2007-12-15 19:34 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1197737505128-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> At this point, I'm only seeking comments about the general direction.
> The patches should not be applied to git.git.
>
> - Do you think something like this would be helpful?
> - Are similar approaches already available?
> - How do you use git to support code review; besides discussing
> patches on mailing lists?
I think there are other good building blocks you can use outside git to
help reviewing evolution of patches (interdiff comes to mind).
When I receive a replacement series to a topic, I use RP script
(available in my 'todo' branch and checked out in Meta/ directory in my
work area, together with other scripts from 'todo'), which:
* finds where the older series were applied;
* detaches HEAD at that commit, and apply the new series;
* runs diff between the old and new;
* updates the tip of that topic with the new series.
After it finishes, "diff topic@{1} topic" becomes the incremental diff
between the old and the new series, and if I do not like the end result,
I can reset --hard back to topic@{1}.
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Alex Riesen @ 2007-12-15 19:37 UTC (permalink / raw)
To: Michael Dressel; +Cc: git
In-Reply-To: <alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos>
Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:
>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>> is not a merge.
>
> Since "git merge --squash <branch>" does a merge of <branch> into the
> working tree why would you not call it a merge?
Because merge, in Git language, means connection histories. That one
just mixes the text. That's different operation, kind of editing a
file.
> Anyway that was what I wanted. Merging <branch> (a topic branch) into my
> current branch (the main branch) but being able to create commits that are
> more suitable for keeping in the history of the current branch than the
> commits I created during developing on <branch>.
> Would you recommend a different way of doing this?
I would not recommend doing it at all. If I must, I'd rather use
git-rebase -i (interactive rebase).
^ permalink raw reply
* Re: trim_common_tail bug?
From: Jeff King @ 2007-12-15 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vprx7n90t.fsf@gitster.siamese.dyndns.org>
On Sat, Dec 15, 2007 at 09:49:06AM -0800, Junio C Hamano wrote:
> Shoot. Thanks for spotting.
>
> Wouldn't it be enough to do:
>
> for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
> while (recovered < trimmed && ap[recovered++] != '\n')
> ; /* nothing */
> }
>
> then (warning: I haven't had my coffee yet)?
Yes, I think that is equivalent. My sleep-deprived brain keeps thinking
there must be a more clear way of writing this whole loop, but it
escapes me at the moment.
-Peff
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Michael Dressel @ 2007-12-15 20:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michael Dressel, Alex Riesen, git
In-Reply-To: <m37ijfrcm5.fsf@roke.D-201>
On Sat, 15 Dec 2007, Jakub Narebski wrote:
> Michael Dressel <MichaelTiloDressel@t-online.de> writes:
>
>> On Fri, 14 Dec 2007, Alex Riesen wrote:
>>
>>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
>>>> On Thu, 13 Dec 2007, Alex Riesen wrote:
>>>>> On 13/12/2007, Michael Dressel wrote:
>>>>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>>>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>>>>> that is because git was able to do a fast forward?
>>>>>
>>>>> Yes. Because fast-forward is what it called: fast-forward.
>>>>> It does not do any commits at all.
>>>>>
>>>>
>>>> It looks like I misunderstood the meaning of --no-commit. I have to use
>>>> --squash in this case.
>>>>
>>>
>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>>> is not a merge.
>>
>> Since "git merge --squash <branch>" does a merge of <branch> into the
>> working tree why would you not call it a merge?
>
> A few illustrations. Commits A, B, C were made on 'trunk', commits
> a, b, c were made on 'branch'. You are on 'trunk', running
> "git merge <options> branch". We assume that there are no conflicts.
>
> 1. A non fast-forward case
>
> 1---2---3---A---B---C <-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
> 1.1. "git merge branch"
>
> 1---2---3---A---B---C--M <-- trunk <-- HEAD
> \ /
> \-a---b---c/ <-- branch
>
> M is _merge_ commits, with two parents: C and c. It was created
> by "git merge branch".
>
> 1.2. "git merge --no-commit branch"
>
> /-------- trunk <-- HEAD
> v
> 1---2---3---A---B---C--*
> \ /
> \-a---b---c/ <-- branch
> ^
> \-------- MERGE_HEAD
>
> The merge commit '*' is prepared, but not yet committed, just
> as if there were merge conflict during merge. "git commit"
> would commit a merge (and would tell you that it does a merge
> commit).
>
> 1.3. "git merge --no-commit --no-ff branch"
>
> Like in 1.2, because it is non fast-forward case.
>
> 1.4. "git merge --squash branch"
>
> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
> "[abc]'" is a _single parent_ commit (it is not a merge commit!)
> which incorporates changes made on branch as if it were made in
> a single, large (!) commit.
>
> 1.5. "git rebase trunk branch" (or "git pull --rebase branch")
>
> 1---2---3---A---B---C <-- trunk
> \
> \-a'--b'--c' <-- branch <-- HEAD
>
> Rebase is step-by-step process, replying commits a, b, c on top
> of trunk, trying for the same _changes_. a', b', c' are newly
> created commits, introducing the same changes as a, b, c if there
> were no rebase conflicts.
>
> I think that "git pull --rebase branch" goes a step further and
> actually does after-rebase fast-forward merge, and does not change
> branch, but I might be mistaken.
>
> 1---2---3---A---B---C---a'--b'--c' <-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
>
> 2. Fast forward case; there are no commits A, B, C, and we
> start from the following situation:
>
> 1---2---3 <-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
> 2.1. "git merge branch"
>
> 1---2---3 /----- trunk <-- HEAD
> \ v
> \-a---b---c <-- branch
>
> Fast forward results in simply moving the head of trunk.
> It does not create a commit, hence:
>
> 2.2. "git merge --no-commit branch"
>
> Like in 2.1, because fast-forwarding does not create a commit.
>
> 2.3. "git merge --no-commit --no-ff branch"
>
> 1---2---3 <-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
> (probably with some error message).
>
Thanks alot for the elaborate explanations.
>
> Test of understanding the concepts: what does
> "git merge --squash --no-commit" does?
>
>From the man page it sounds "git merge --squash --no-commit" would do the
same as "git merge --squash". So in the example 1.4 [abc] should not be a
commit.
Cheers,
Michael
^ permalink raw reply
* Oddity in git commit summary
From: Daniel Barkalow @ 2007-12-15 20:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I just noticed that I got a strange summary from git commit -a --amend
with the current master. It said:
Created commit f16cb29: Build in checkout
5 files changed, 482 insertions(+), 299 deletions(-)
create mode 100644 builtin-checkout.c
delete mode 100755 git-checkout.sh
But git show --stat says:
7 files changed, 780 insertions(+), 306 deletions(-)
And git show --stat -C says:
6 files changed, 482 insertions(+), 8 deletions(-)
The commit that I noticed this on is available from:
git://iabervon.org/~barkalow/git.git builtin-checkout
I've never particularly paid attention to this message before, so I don't
know if it's saying something accurate I'm not understanding, or if it's
actually inaccurate about what it's trying to show.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Michael Dressel @ 2007-12-15 20:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: B.Steinbrink, git
In-Reply-To: <20071215193741.GB3021@steel.home>
On Sat, 15 Dec 2007, Alex Riesen wrote:
> Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:
>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>>> is not a merge.
>>
>> Since "git merge --squash <branch>" does a merge of <branch> into the
>> working tree why would you not call it a merge?
>
> Because merge, in Git language, means connection histories. That one
> just mixes the text. That's different operation, kind of editing a
> file.
That's a nice clarification. In my case I wanted that "just mixes the
text" thing because I did aggressively do commits during development
trying out slightly different approaches and being able to go back to compare
them. These different games are not interesting to keep in the history
once a good solution has been found.
>
>> Anyway that was what I wanted. Merging <branch> (a topic branch) into my
>> current branch (the main branch) but being able to create commits that are
>> more suitable for keeping in the history of the current branch than the
>> commits I created during developing on <branch>.
>> Would you recommend a different way of doing this?
>
> I would not recommend doing it at all. If I must, I'd rather use
> git-rebase -i (interactive rebase).
>
>
Yes I didn't use rebase sofar. I should consider it sometimes.
Cheers,
Michael
^ permalink raw reply
* Post-1.5.4 stuff: builtin-checkout
From: Daniel Barkalow @ 2007-12-15 20:44 UTC (permalink / raw)
To: git
I've got my builtin-checkout implementation at:
git://iabervon.org/~barkalow/git.git builtin-checkout
This may be interesting to some other people at this point, despite it not
being relevant to 1.5.4, because (a) it includes a slew of small
preliminary patches to other stuff that might be useful for making other
things builtin and (b) these changes reflect my debugging of my naive
implementation of builtin-checkout, and may suggest things that might be
wrong in existing builtins that do multiple operations in the same
process.
I'll actually send patches to the list post-1.5.4 of all this stuff.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Jakub Narebski @ 2007-12-15 20:57 UTC (permalink / raw)
To: Michael Dressel; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LSU.0.99999.0712152117060.5151@castor.milkiway.cos>
Michael Dressel <MichaelTiloDressel@t-online.de> writes:
> On Sat, 15 Dec 2007, Jakub Narebski wrote:
>> Michael Dressel <MichaelTiloDressel@t-online.de> writes:
>>>
>>> Since "git merge --squash <branch>" does a merge of <branch> into the
>>> working tree why would you not call it a merge?
>>
>> A few illustrations. Commits A, B, C were made on 'trunk', commits
>> a, b, c were made on 'branch'. You are on 'trunk', running
>> "git merge <options> branch". We assume that there are no conflicts.
>>
>> 1. A non fast-forward case
>>
>> 1---2---3---A---B---C <-- trunk <-- HEAD
>> \
>> \-a---b---c <-- branch
>> 1.2. "git merge --no-commit branch"
>>
>> /-------- trunk <-- HEAD
>> v
>> 1---2---3---A---B---C--*
>> \ /
>> \-a---b---c/ <-- branch
>> ^
>> \-------- MERGE_HEAD
>>
>> The merge commit '*' is prepared, but not yet committed, just
>> as if there were merge conflict during merge. "git commit"
>> would commit a merge (and would tell you that it does a merge
>> commit).
>> 1.4. "git merge --squash branch"
>>
>> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD
>> \
>> \-a---b---c <-- branch
>>
>> "[abc]'" is a _single parent_ commit (it is not a merge commit!)
>> which incorporates changes made on branch as if it were made in
>> a single, large (!) commit.
>
> Thanks alot for the elaborate explanations.
You are welcome
>> Test of understanding the concepts: what does
>> "git merge --squash --no-commit" does?
>>
>
> From the man page it sounds "git merge --squash --no-commit" would do
> the same as "git merge --squash". So in the example 1.4 [abc] should
> not be a commit.
/---------\
v \
1---2---3---A---B---C--*[abc]' \-- trunk <-- HEAD
\
\-a---b---c <-- branch
where *[abc]' is prepared state (staged but not committed changes)
squashing achanges into commits a, b, c into trunk.
Note that using "git rebase --interactive" you can squash, reorder
and edit commits; if you rather work in this way, reordering, editing
etc. "on the go" you perhaps should consider patch-management
interfaces like StGIT (Stacked GIT) or Guilt (formerly gq).
BTW. in practice [abc]' in squash case is the same as M in normal
case, only M has two parents recorded, and [abc]' does not.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Wrong Git rename detection results
From: Martin Koegler @ 2007-12-15 21:14 UTC (permalink / raw)
To: git
I have reworked parts of my bcusdk repository in a separate branch
(6d102933f620b81b4a2c09046ec529460bd0c90f), which I merged into master
(9068de13cb408babf4206aa5ee55a7f8094f4ff3).
I'm interessed in the resulting differenced of the merge:
http://repo.or.cz/w/bcusdk.git?a=commitdiff;h=9068de13cb408babf4206aa5ee55a7f8094f4ff3;hp=6d102933f620b81b4a2c09046ec529460bd0c90f
The output of git is totally absurd. It tells me, that I moved a C
file to a java file with about 70% similarity, many other C files
where copied from one C file with 70% to 80% similarity, misses an
move with new lines added (eibd/client/eibclient-int.h =>
eibd/client/c/eibclient-int.h) and so on.
Additionally, it states, that files were moved to unrelated files, eg:
eibd/client/def/mcprogmodeoff.inc [moved from eibd/client/openvbusmonitor.c with 60% similarity]
In this case, eibd/client/mcprogmodeoff.def would have been the
correct logical successor.
With git 1.5.4.rc0.1122.g5512, the rename detection yields to slightly different
results, which are also not correct.
I guess, that the problem is triggered by the fact all files
are short and share a common (big) license header.
mfg Martin Kögler
PS:
I don't doubt, that the results are technical correct (files have the
printed similarity).
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Michael Dressel @ 2007-12-15 21:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <m33au3r7zf.fsf@roke.D-201>
On Sat, 15 Dec 2007, Jakub Narebski wrote:
> Michael Dressel writes:
>> On Sat, 15 Dec 2007, Jakub Narebski wrote:
>>> Michael Dressel writes:
>>>>
>>>> Since "git merge --squash <branch>" does a merge of <branch> into the
>>>> working tree why would you not call it a merge?
>>>
>>> A few illustrations. Commits A, B, C were made on 'trunk', commits
>>> a, b, c were made on 'branch'. You are on 'trunk', running
>>> "git merge <options> branch". We assume that there are no conflicts.
>>>
>>> 1. A non fast-forward case
>>>
>>> 1---2---3---A---B---C <-- trunk <-- HEAD
>>> \
>>> \-a---b---c <-- branch
>
>>> 1.2. "git merge --no-commit branch"
>>>
>>> /-------- trunk <-- HEAD
>>> v
>>> 1---2---3---A---B---C--*
>>> \ /
>>> \-a---b---c/ <-- branch
>>> ^
>>> \-------- MERGE_HEAD
>>>
>>> The merge commit '*' is prepared, but not yet committed, just
>>> as if there were merge conflict during merge. "git commit"
>>> would commit a merge (and would tell you that it does a merge
>>> commit).
>
>>> 1.4. "git merge --squash branch"
>>>
>>> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD
>>> \
>>> \-a---b---c <-- branch
>>>
>>> "[abc]'" is a _single parent_ commit (it is not a merge commit!)
>>> which incorporates changes made on branch as if it were made in
>>> a single, large (!) commit.
>>
>> Thanks alot for the elaborate explanations.
>
> You are welcome
>
>>> Test of understanding the concepts: what does
>>> "git merge --squash --no-commit" does?
>>>
>>
>> From the man page it sounds "git merge --squash --no-commit" would do
>> the same as "git merge --squash". So in the example 1.4 [abc] should
>> not be a commit.
>
> /---------\
> v \
> 1---2---3---A---B---C--*[abc]' \-- trunk <-- HEAD
> \
> \-a---b---c <-- branch
>
> where *[abc]' is prepared state (staged but not committed changes)
> squashing achanges into commits a, b, c into trunk.
>
> Note that using "git rebase --interactive" you can squash, reorder
> and edit commits; if you rather work in this way, reordering, editing
> etc. "on the go" you perhaps should consider patch-management
> interfaces like StGIT (Stacked GIT) or Guilt (formerly gq).
>
> BTW. in practice [abc]' in squash case is the same as M in normal
> case, only M has two parents recorded, and [abc]' does not.
Thanks again. There is a lot for me to practice now.
Cheers,
Michael
^ permalink raw reply
* One of my commits is missing
From: Luke Diamand @ 2007-12-15 22:16 UTC (permalink / raw)
To: git
My last commit seems to have vanished, and I wonder if anyone knows
where it might have gone.
I had a branch with a big pile of changes on it, and I merged those onto
a second branch to tidy it all up and fix one last bug.
I did a git-commit, and then created a third branch to start some other
unrelated work (git-checkout -b ...).
Now that second branch no longer has my last commit.
Obviously most of my changes are still on the first branch, but I'd
quite like to get back my commit.
Looking through my history I don't see any signs of errant git-reset's
so I'm baffled.
Any ideas?
Thanks
Luke Diamand
^ permalink raw reply
* Re: git-browse-help?
From: Shawn O. Pearce @ 2007-12-15 22:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Christian Couder, git
In-Reply-To: <20071215111154.GB3447@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> -- >8 --
> teach bash completion to treat commands with "--" as plumbing
>
> There is a convention that commands containing a double-dash
> are implementation details and not to be used by mortals. We
> should automatically remove them from the completion
> suggestions as plumbing.
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 58e0e53..2fd32db 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -291,7 +291,7 @@ __git_commands ()
> for i in $(git help -a|egrep '^ ')
> do
> case $i in
> - add--interactive) : plumbing;;
> + *--*) : plumbing pattern;;
> applymbox) : ask gittus;;
> applypatch) : ask gittus;;
> archimport) : import;;
> @@ -308,7 +308,6 @@ __git_commands ()
> diff-tree) : plumbing;;
> fast-import) : import;;
> fsck-objects) : plumbing;;
> - fetch--tool) : plumbing;;
> fetch-pack) : plumbing;;
> fmt-merge-msg) : plumbing;;
> for-each-ref) : plumbing;;
--
Shawn.
^ permalink raw reply
* Re: One of my commits is missing
From: Shawn O. Pearce @ 2007-12-15 22:29 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <47645232.7050502@vidanti.com>
Luke Diamand <luke@vidanti.com> wrote:
>
> My last commit seems to have vanished, and I wonder if anyone knows
> where it might have gone.
...
> Looking through my history I don't see any signs of errant git-reset's
> so I'm baffled.
I'm baffled too. Have a look at your HEAD reflog and see if you
can find it there (`git log -g`) as if you actually did in fact
create it with git-commit it should appear in that reflog for at
least the next 90 days (by default config anyway).
--
Shawn.
^ permalink raw reply
* [PATCH] threaded pack-objects: Use condition variables for thread communication.
From: Johannes Sixt @ 2007-12-15 23:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Junio C Hamano
In the threaded pack-objects code the main thread and the worker threads
must mutually signal that they have assigned a new pack of work or have
completed their work, respectively. Previously, the code used mutexes that
were locked in one thread and unlocked from a different thread, which is
bogus (and happens to work on Linux).
Here we rectify the implementation by using condition variables: There is
one condition variable on which the main thread waits until a thread
requests new work; and each worker thread has its own condition variable
on which it waits until it is assigned new work or signaled to terminate.
As a cleanup, the worker threads are spawned only after the initial work
packages have been assigned.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-pack-objects.c | 129 +++++++++++++++++++++++++++++------------------
1 files changed, 79 insertions(+), 50 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7dd0d7f..451e48e 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1594,6 +1594,15 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
#ifdef THREADED_DELTA_SEARCH
+/*
+ * The main thread waits on the condition that (at least) one of the workers
+ * has stopped working (which is indicated in the .working member of
+ * struct thread_params).
+ * When a work thread has completed its work, it sets .working to 0 and
+ * signals the main thread and waits on the condition that .data_ready
+ * becomes 1.
+ */
+
struct thread_params {
pthread_t thread;
struct object_entry **list;
@@ -1601,37 +1610,50 @@ struct thread_params {
unsigned remaining;
int window;
int depth;
+ int working;
+ int data_ready;
+ pthread_mutex_t mutex;
+ pthread_cond_t cond;
unsigned *processed;
};
-static pthread_mutex_t data_request = PTHREAD_MUTEX_INITIALIZER;
-static pthread_mutex_t data_ready = PTHREAD_MUTEX_INITIALIZER;
-static pthread_mutex_t data_provider = PTHREAD_MUTEX_INITIALIZER;
-static struct thread_params *data_requester;
+static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
static void *threaded_find_deltas(void *arg)
{
struct thread_params *me = arg;
- for (;;) {
- pthread_mutex_lock(&data_request);
- data_requester = me;
- pthread_mutex_unlock(&data_provider);
- pthread_mutex_lock(&data_ready);
- pthread_mutex_unlock(&data_request);
-
- if (!me->remaining)
- return NULL;
-
+ while (me->remaining) {
find_deltas(me->list, &me->remaining,
me->window, me->depth, me->processed);
+
+ progress_lock();
+ me->working = 0;
+ progress_unlock();
+ pthread_cond_signal(&progress_cond);
+
+ /*
+ * We must not set ->data_ready before we wait on the
+ * condition because the main thread may have set it to 1
+ * before we get here. In order to be sure that new
+ * work is available if we see 1 in ->data_ready, it
+ * was initialized to 0 before this thread was spawned
+ * and we reset it to 0 right away.
+ */
+ pthread_mutex_lock(&me->mutex);
+ while (!me->data_ready)
+ pthread_cond_wait(&me->cond, &me->mutex);
+ me->data_ready = 0;
+ pthread_mutex_unlock(&me->mutex);
}
+ /* leave ->working 1 so that this doesn't get more work assigned */
+ return NULL;
}
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
int window, int depth, unsigned *processed)
{
- struct thread_params *target, p[delta_search_threads];
+ struct thread_params p[delta_search_threads];
int i, ret, active_threads = 0;
if (delta_search_threads <= 1) {
@@ -1639,49 +1661,42 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
return;
}
- pthread_mutex_lock(&data_provider);
- pthread_mutex_lock(&data_ready);
-
- /* Start work threads. */
+ /* Partition the work amongst work threads. */
for (i = 0; i < delta_search_threads; i++) {
+ unsigned sub_size = list_size / (delta_search_threads - i);
+
p[i].window = window;
p[i].depth = depth;
p[i].processed = processed;
- p[i].remaining = 0;
- ret = pthread_create(&p[i].thread, NULL,
- threaded_find_deltas, &p[i]);
- if (ret)
- die("unable to create thread: %s", strerror(ret));
- active_threads++;
- }
-
- /* Then partition the work amongst them. */
- for (i = 0; i < delta_search_threads; i++) {
- unsigned sub_size = list_size / (delta_search_threads - i);
-
- pthread_mutex_lock(&data_provider);
- target = data_requester;
- if (!sub_size) {
- pthread_mutex_unlock(&data_ready);
- pthread_join(target->thread, NULL);
- active_threads--;
- continue;
- }
+ p[i].working = 1;
+ p[i].data_ready = 0;
+ pthread_mutex_init(&p[i].mutex, NULL);
+ pthread_cond_init(&p[i].cond, NULL);
/* try to split chunks on "path" boundaries */
while (sub_size < list_size && list[sub_size]->hash &&
list[sub_size]->hash == list[sub_size-1]->hash)
sub_size++;
- target->list = list;
- target->list_size = sub_size;
- target->remaining = sub_size;
- pthread_mutex_unlock(&data_ready);
+ p[i].list = list;
+ p[i].list_size = sub_size;
+ p[i].remaining = sub_size;
list += sub_size;
list_size -= sub_size;
}
+ /* Start work threads. */
+ for (i = 0; i < delta_search_threads; i++) {
+ if (!p[i].list_size)
+ continue;
+ ret = pthread_create(&p[i].thread, NULL,
+ threaded_find_deltas, &p[i]);
+ if (ret)
+ die("unable to create thread: %s", strerror(ret));
+ active_threads++;
+ }
+
/*
* Now let's wait for work completion. Each time a thread is done
* with its work, we steal half of the remaining work from the
@@ -1690,13 +1705,21 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
* until the remaining object list segments are simply too short
* to be worth splitting anymore.
*/
- do {
+ while (active_threads) {
+ struct thread_params *target = NULL;
struct thread_params *victim = NULL;
unsigned sub_size = 0;
- pthread_mutex_lock(&data_provider);
- target = data_requester;
progress_lock();
+ for (;;) {
+ for (i = 0; !target && i < delta_search_threads; i++)
+ if (!p[i].working)
+ target = &p[i];
+ if (target)
+ break;
+ pthread_cond_wait(&progress_cond, &progress_mutex);
+ };
+
for (i = 0; i < delta_search_threads; i++)
if (p[i].remaining > 2*window &&
(!victim || victim->remaining < p[i].remaining))
@@ -1723,17 +1746,23 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
victim->list_size -= sub_size;
victim->remaining -= sub_size;
}
- progress_unlock();
-
target->list_size = sub_size;
target->remaining = sub_size;
- pthread_mutex_unlock(&data_ready);
+ target->working = 1;
+ progress_unlock();
+
+ pthread_mutex_lock(&target->mutex);
+ target->data_ready = 1;
+ pthread_mutex_unlock(&target->mutex);
+ pthread_cond_signal(&target->cond);
if (!sub_size) {
pthread_join(target->thread, NULL);
+ pthread_cond_destroy(&target->cond);
+ pthread_mutex_destroy(&target->mutex);
active_threads--;
}
- } while (active_threads);
+ }
}
#else
--
1.5.3.6.954.g0c63
^ permalink raw reply related
* [PATCH] Allow commit (and tag) messages to be edited when $EDITOR has arguments
From: Steven Grimm @ 2007-12-16 1:12 UTC (permalink / raw)
To: git
Users who do EDITOR="/usr/bin/emacs -nw" or similar were left unable to
edit commit messages once commit became a builtin, because the editor
launch code assumed that $EDITOR was a single pathname.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Looked around but didn't see an existing "build a char* array
out of a delimited string" function in the git source; if one
exists, of course it should be used instead of my pair of loops
here.
builtin-tag.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 274901a..dace758 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -47,10 +47,35 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
editor = "vi";
if (strcmp(editor, ":")) {
- const char *args[] = { editor, path, NULL };
+ char *editor_copy, *c;
+ int args_size = 3, args_pos = 0;
+ char **args;
+
+ /* Parse the editor command, since it can contain arguments.
+ * First count the number of arguments so we can allocate an
+ * appropriately-sized arg array.
+ */
+ editor_copy = xstrdup(editor);
+ for (c = editor_copy; *c != '\0'; c++) {
+ if (*c == ' ') {
+ args_size++;
+ }
+ }
+
+ args = xmalloc(sizeof(char *) * args_size);
+ for (c = strtok(editor_copy, " "); c != NULL;
+ c = strtok(NULL, " ")) {
+ args[args_pos++] = c;
+ }
+
+ args[args_pos++] = path;
+ args[args_pos++] = NULL;
if (run_command_v_opt_cd_env(args, 0, NULL, env))
die("There was a problem with the editor %s.", editor);
+
+ free(args);
+ free(editor_copy);
}
if (!buffer)
--
1.5.4.rc0
^ permalink raw reply related
* Re: [PATCH] Allow commit (and tag) messages to be edited when $EDITOR has arguments
From: Johannes Schindelin @ 2007-12-16 1:41 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071216011201.GA10867@midwinter.com>
Hi,
On Sat, 15 Dec 2007, Steven Grimm wrote:
> Looked around but didn't see an existing "build a char* array
> out of a delimited string" function in the git source; if one
> exists, of course it should be used instead of my pair of loops
> here.
Did you look for split_cmdline() in git.c? IMHO it should move to
run-command.c and be made public.
Thanks,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox