* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-28 1:29 UTC (permalink / raw)
To: git
In-Reply-To: <gj68a0$u56$3@ger.gmane.org>
tidied up the formatting, added a few more comments where needed, fixed
errors/lack of clarity
"Zorba" <cr@altmore.co.uk> wrote in message
news:gj68a0$u56$3@ger.gmane.org...
> Here is a little exercise / tutorial / warm-up for someone starting out
> with Git. If you're anyting like me you may find the tutorials etc. on
> git.or.cz a bit daunting. I recommend you try this after reading the user
> manual but before tearing your hair out trying to follow all the examples
> in the user manual. After you've followed this simple workflow, then go
> back to the more advanced stuff in the tutorials and user manuals (like
> cloning repositories and creating and merging branches).
>
> I created this exercise to try and model our workflow and what we wanted
> to use git for = tracking a project with multiple files where the filebase
> might change frequently from one version to the next.
>
> http://siliconmouth.wordpress.com/category/nerdy/
>
> look for December 27, 2008 or "git warmup"
>
>
^ permalink raw reply
* Re: [PATCH 3/3] pretty: support multiline subjects with format:
From: Miklos Vajna @ 2008-12-28 1:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: markus.heidelberg, René Scharfe, git
In-Reply-To: <20081228090909.6117@nanako3.lavabit.com>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Sun, Dec 28, 2008 at 09:09:09AM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> The last message mentions a bug in "git rebase" that internally uses
> "git am" when replaying the changes. It was corrected later with:
>
> http://thread.gmane.org/gmane.linux.ports.sh.devel/3833/focus=79735
>
> Reading the discussion in the messages in this thread will help
> understanding the issues, after understanding why "the first line" was
> problematic, as discussed in the other threads.
Actually in that thread I asked if a patch that would make this
configurable would be ever accepted (so I would work on it), but I got
no answer. In the meantime I just learned to live with this, partially
because the vim highlight script highlights anything written to the
second line as red. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: Fix export check in git_get_projects_list
From: Jakub Narebski @ 2008-12-28 2:12 UTC (permalink / raw)
To: Devin Doucette; +Cc: git, Petr Baudis
In-Reply-To: <a899d7ef0812270139u7dd28ee1q45a8c05f7c95db2f@mail.gmail.com>
On Sat, 27 Dec 2008, Devin Doucette wrote:
> When $filter was empty, the path passed to check_export_ok would
> contain an extra '/', which some implementations of export_auth_hook
> are sensitive to.
>
> It makes more sense to fix this here than to handle the special case
> in each implementation of export_auth_hook.
>
> Signed-off-by: Devin Doucette <devin@doucette.cc>
Good catch. Thanks.
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 8f574c7..99f71b4 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2147,8 +2147,9 @@ sub git_get_projects_list {
>
> my $subdir = substr($File::Find::name, $pfxlen + 1);
> # we check related file in $projectroot
> - if (check_export_ok("$projectroot/$filter/$subdir")) {
> - push @list, { path => ($filter ? "$filter/" : '') . $subdir };
> + my $path = ($filter ? "$filter/" : '') . $subdir;
Nice and clear, but wouldn't be better to use slightly more effective
+ my $path = $filter ? "$filter/$subdir" : $subdir;
Or even, taking care of the case when $filter eq '0'
+ my $path = defined $filter && $filter ne '' ? "$filter/$subdir" : $subdir;
> + if (check_export_ok("$projectroot/$path")) {
> + push @list, { path => $path };
> $File::Find::prune = 1;
> }
> },
> --
> 1.6.1.rc4
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation/diff-options.txt: unify options
From: Junio C Hamano @ 2008-12-28 6:52 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87lju1jmp9.fsf@jidanni.org>
jidanni@jidanni.org writes:
> JCH> Sorry, but this patch is very unusual in that it lacks any context lines,
> JCH> which makes it impossible to review.
>
> Trust me, I tried it with the default context lines and it was just
> the same hard reading.
Nonsense.
Here is a snippet from your patch.
diff --git a/diff-options.txt b/diff-options.txt
index 5721548..b05503a 100644
--- a/diff-options.txt
+++ b/diff-options.txt
@@ -21,0 +22 @@ ifndef::git-format-patch[]
+-u::
@@ -26,3 +26,0 @@ endif::git-format-patch[]
--u::
- Synonym for "-p".
-
The only thing anybody can guess without looking at the original (that is
what "sending a patch without context" means) is that you moved "-u::" to
somewhere else, and stripped of its description. There is absolutely no
clue to judge if the new home to "-u::" is an appropriate place.
In a normal patch with context, the same hunk would have looked like this:
diff --git i/Documentation/diff-options.txt w/Documentation/diff-options.txt
index c62b45c..c4ca0a9 100644
--- i/Documentation/diff-options.txt
+++ w/Documentation/diff-options.txt
@@ -19,16 +19,12 @@ endif::git-format-patch[]
ifndef::git-format-patch[]
-p::
+-u::
Generate patch (see section on generating patches).
{git-diff? This is the default.}
endif::git-format-patch[]
--u::
- Synonym for "-p".
-
-U<n>::
- Shorthand for "--unified=<n>".
-
--unified=<n>::
Presented this way, it is much more clear what is going on, as there is no
need to go back to the original and see if the new location for "-u::"
makes sense (and I think it does, but that is something I can say after
applying the patch and reviewing the result, because the patch itself is
not reviewable).
If you find yours just as easy to read as the one with context, your patch
reading ability far exceeds mine, and I'd refuse to read your patches in
the future to preserve my sanity.
There is another issue that should be obvious to people who deal with
patches every day. The context-free patch you sent can be applied *ONLY*
after locating the *EXACT* preimage of the file you used to produce your
patch. Before your patch is reviewed, other people may have already
modified the same file, perhaps introducing a few new lines at the top of
the file, and then what? Your first hunk tells us that you would want to
insert a line with "-u::" at line #21, but the context does not match
anymore when your patch is reviewed.
^ permalink raw reply
* Re: [PATCH 2/2] grep: grep cache entries if they are "assume unchanged"
From: Junio C Hamano @ 2008-12-28 6:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Daniel Barkalow
In-Reply-To: <1230366064-1306-1-git-send-email-pclouds@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix export check in git_get_projects_list
From: Junio C Hamano @ 2008-12-28 6:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Devin Doucette, git, Petr Baudis
In-Reply-To: <200812280312.02615.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Sat, 27 Dec 2008, Devin Doucette wrote:
>
>> When $filter was empty, the path passed to check_export_ok would
>> contain an extra '/', which some implementations of export_auth_hook
>> are sensitive to.
>>
>> It makes more sense to fix this here than to handle the special case
>> in each implementation of export_auth_hook.
>>
>> Signed-off-by: Devin Doucette <devin@doucette.cc>
>
> Good catch. Thanks.
Thanks, both. Will queue for 'maint'.
^ permalink raw reply
* [PATCH] gitweb: Handle actions with no project in evaluate_path_info
From: Devin Doucette @ 2008-12-28 7:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis
The action would not be set if no valid project was found in
path_info. Removing the return if the project was not specified fixes
the project_index and opml actions when using path_info.
Signed-off-by: Devin Doucette <devin@doucette.cc>
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8f574c7..b6a8ea9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -552,8 +552,7 @@ sub evaluate_path_info {
while ($project && !check_head_link("$projectroot/$project")) {
$project =~ s,/*[^/]*$,,;
}
- return unless $project;
- $input_params{'project'} = $project;
+ $input_params{'project'} = $project if $project;
# do not change any parameters if an action is given using the query string
return if $input_params{'action'};
--
1.6.1.rc4
^ permalink raw reply related
* user manual question
From: Zorba @ 2008-12-28 11:07 UTC (permalink / raw)
To: git
Under "Examining an old version without creating a new branch" subsection in
chapter1
to aid my understanding, could the statement:
"The HEAD then refers to the SHA1 of the commit instead of to a branch, and
git branch shows that you are no longer on a branch:"
be restated more explicitly as:
"The HEAD then refers to the SHA1 of the commit instead of to a branch head,
and git branch shows that you are no longer on a branch head:"
?
^ permalink raw reply
* [PATCH] gitk: try to provide a window icon
From: Giuseppe Bilotta @ 2008-12-28 11:28 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
Try to set up a 16x16 Tk photo image (based on the git logo) and use it
as window icon. Wrap the code in a catch because it may fail in earlier
Tcl/Tk 8.4 releases that don't provide 'wm iconphoto'.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Resend (with a typo fixed in the commit message), because it seems to
have flied a little too low on the previous round of commits.
gitk-git/gitk | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index dc2a439..8c6a50d 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10881,6 +10881,26 @@ set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
makewindow
+catch {
+ image create photo gitlogo -width 16 -height 16
+
+ image create photo gitlogominus -width 4 -height 2
+ gitlogominus put #C00000 -to 0 0 4 2
+ gitlogo copy gitlogominus -to 1 5
+ gitlogo copy gitlogominus -to 6 5
+ gitlogo copy gitlogominus -to 11 5
+ image delete gitlogominus
+
+ image create photo gitlogoplus -width 4 -height 4
+ gitlogoplus put #008000 -to 1 0 3 4
+ gitlogoplus put #008000 -to 0 1 4 3
+ gitlogo copy gitlogoplus -to 1 9
+ gitlogo copy gitlogoplus -to 6 9
+ gitlogo copy gitlogoplus -to 11 9
+ image delete gitlogoplus
+
+ wm iconphoto . -default gitlogo
+}
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-28 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <7vskopwxej.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 02:22:28AM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
> > On Sun, Dec 14, 2008 at 07:34:46PM -0800, Junio C Hamano wrote:
> >> merge-recursive: do not clobber untracked working tree garbage
> >>
> >> When merge-recursive wanted to create a new file in the work tree (either
> >> as the final result, or a hint for reference purposes while delete/modify
> >> conflicts), it unconditionally overwrote an untracked file in the working
> >> tree. Be careful not to lose whatever the user has that is not tracked.
> >
> > This leaves the index in an unmerged state, however, so that a subsequent
> > git reset --hard still kills the file. And I just realized that the same
> > goes for merge-resolve. So I'd prefer to abort the merge, leave everything
> > unchanged and tell the user to clean up first.
>
> That is unfortunately asking for a moon, I am afraid.
>
> It needs a major restructuring of the code so that the recursive works
> more like the way resolve works, namely, changing the final "writeout"
> into two phase thing (the first phase making sure nothing is clobbered in
> the work tree, and then the second phase actually touching the work tree).
I've been giving this some thought and I would like to propose the following
solution:
1. Save index state.
2. Merge using whichever strategy, in index only, ignoring work tree.
This step includes rename detection.
3. Check that work tree files match original index, if index does not match
HEAD. Otherwise abort, restore index and leave everything unchanged.
4. Checkout index, overwriting work tree files, and removing files which are
in HEAD, but not in the index.
5. If the merge was clean, commit.
AFAICS, this is largely the behavior right now, except that steps 3 and 4
are intermingled with step 2, which makes it impossible to abort the merge
if an untracked file is in the way after rename detection.
The idea at step 3 is that we can decide whether or not to proceed, based
only on the merge result, irrespective of the strategy used, possible rename
detection, or conflict resolution.
Apart from the fact that this seems like the sane thing to do, I want this
behavior because it allows me to do
git merge <branch>
# Conflicts? I don't have time for that now.
git reset --hard HEAD
under all circumstances, without touching any untracked files.
Do you agree that this is a desireable goal?
I have not looked into d/f conflicts, but I am under the impression that
this could also be handled at step 3, as far as the work tree is concerned.
Is the above proposal a workable approach, which I can pursue independently
of the major rewrite wrt. d/f conflicts Johannes indicated?
^ permalink raw reply
* Re: [PATCH 3/3] pretty: support multiline subjects with format:
From: Markus Heidelberg @ 2008-12-28 14:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: René Scharfe, git
In-Reply-To: <20081228090909.6117@nanako3.lavabit.com>
Nanako Shiraishi, 28.12.2008:
> Quoting Markus Heidelberg <markus.heidelberg@web.de>:
>
> >> For consistency and increased code reuse, change format: to do the
> >> same as the other options.
> >
> > What's wrong with using the first line instead of the first paragraph
> > for the other pretty options and for cases where only a small subject
> > line is desired?
>
> There were too many issues. The mail archive tells us that there were
> considerable discussions and thoughts behind the current behavior:
Many thanks for all the pointers. I thought there were reasons, but this
thread just made me ask.
Markus
^ permalink raw reply
* Re: [PATCH 3/3] pretty: support multiline subjects with format:
From: Markus Heidelberg @ 2008-12-28 14:16 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4956C47B.4020602@lsrfire.ath.cx>
René Scharfe, 28.12.2008:
> Markus Heidelberg schrieb:
> >> For consistency and increased code reuse, change format: to do the
> >> same as the other options.
> >
> > What's wrong with using the first line instead of the first paragraph
> > for the other pretty options and for cases where only a small subject
> > line is desired? A sentence would be broken into a small uncomplete part
> > for the subject for example. What else?
>
> I'm inching towards the goal of being able to replicate all of the other
> --pretty flavours with format: (or tformat:) strings.
>
> --pretty=oneline used to print only the first line, but was changed to
> the way it's now in 4234a761 more than a year ago. In my mind,
> "subject" is defined by "what oneline is printing", so I think changing
> the format: placeholder %s to show the whole first paragraph is a bug fix.
Yes, now I think so, too. I had also noticed the unexpectedly different
behaviour once.
> If you actually like the old behaviour then perhaps a new placeholder
> (%S ?) should be introduced instead?
I don't need it. I rather asked regarding the old behaviour for oneline
and so, but reading that there are strong intentions for their
behaviour, it's fine.
Markus
^ permalink raw reply
* Re: [PATCH 3/3] pretty: support multiline subjects with format:
From: Markus Heidelberg @ 2008-12-28 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git
In-Reply-To: <7vr63tb1i2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 28.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > What's wrong with using the first line instead of the first paragraph
> > for the other pretty options and for cases where only a small subject
> > line is desired? A sentence would be broken into a small uncomplete part
> > for the subject for example. What else?
>
> The "first line" actually was what we used to do originally.
>
> git-native commits did not have problem with this behaviour, but it caused
> countless complaints from people looking at the history converted from
> other cultures.
>
> The behaviour was later fixed to avoid information loss when a commit from
> a different culture begins the log with a long sentence, choped at
> mid-sentence, to continue to the second line.
>
> Please check the list archive for the details (sorry, I am bit too lazy to
> repeat the argument myself).
I don't call this lazy. Normally I look myself and don't want others to
spend time on searching for me. Reading that there already were
discussions about this and that the current behaviour is thoughtful is
enough for me to look for details myself. Thanks.
Markus
^ permalink raw reply
* Re: user manual question
From: Sitaram Chamarty @ 2008-12-28 14:38 UTC (permalink / raw)
To: git
In-Reply-To: <gj7mmo$fvk$4@ger.gmane.org>
On 2008-12-28, Zorba <cr@altmore.co.uk> wrote:
> Under "Examining an old version without creating a new branch" subsection in
> chapter1
>
> to aid my understanding, could the statement:
>
> "The HEAD then refers to the SHA1 of the commit instead of to a branch, and
> git branch shows that you are no longer on a branch:"
>
> be restated more explicitly as:
>
> "The HEAD then refers to the SHA1 of the commit instead of to a branch head,
> and git branch shows that you are no longer on a branch head:"
Sure, but I prefer "tip"; reduces confusion between "head"
and "HEAD" in spoken descriptions (I teach internal classes
on git occasionally, once even on a conf call!)
The git glossary makes no mention of "tip", so this is
probably "unblessed" :-)
^ permalink raw reply
* Re: user manual question
From: Dilip M @ 2008-12-28 16:36 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrnglf3qh.c7j.sitaramc@sitaramc.homelinux.net>
On Sun, Dec 28, 2008 at 8:08 PM, <sitaramc@gmail.com> wrote:
> On 2008-12-28, Zorba <cr@altmore.co.uk> wrote:
>> Under "Examining an old version without creating a new branch"
>> subsection in chapter1
>>
>> to aid my understanding, could the statement:
>>
>> "The HEAD then refers to the SHA1 of the commit instead of to a
>> branch, and git branch shows that you are no longer on a branch:"
>>
>> be restated more explicitly as:
>>
>> "The HEAD then refers to the SHA1 of the commit instead of to a
>> branch head, and git branch shows that you are no longer on a branch
>> head:"
>
> Sure, but I prefer "tip"; reduces confusion between "head" and "HEAD"
> in spoken descriptions (I teach internal classes on git occasionally,
> once even on a conf call!)
+1
I was (am) was initially confused about head and HEAD and assumed that
they are both same.
-- dm
^ permalink raw reply
* gitk Branch: field problem with 1.6.1
From: Hannu Koivisto @ 2008-12-28 16:53 UTC (permalink / raw)
To: git
Greetings,
If I create a test repository as follows...
mkdir gitktest
cd gitktest
git init
echo foo > foo
git add foo
git commit -m "foo"
echo bar >> foo
git add foo
git commit -m "bar"
git checkout -b branch HEAD~1
echo baz > baz
git add baz
git commit -m "baz"
echo baz >> baz
git add baz
git commit -m "more baz"
git checkout -b debug2
echo baz >> baz
git add baz
git commit -m "even more baz"
...and with gitk --all look at the "more baz" commit, it says
"Branch: debug2" as shown here
<http://www.iki.fi/azure/tmp/gitk-test1.png>. My understanding is
that it should show "Branches: branch, debug2" but I might be wrong
of course.
I have another test repository (I can make a creation recipe or
make the repository available for download if needed) where, in
addition to the problem above, gitk shows empty "Branch:" field for
the master branch's tip commit.
Both tests made with 1.6.1 on Linux.
--
Hannu
^ permalink raw reply
* Re: [PATCH] gitrepository-layout: No longer first two letters. Also add "down".
From: Sverre Rabbelier @ 2008-12-28 17:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: jidanni, git
In-Reply-To: <20081227070232.6117@nanako3.lavabit.com>
On Fri, Dec 26, 2008 at 16:02, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting jidanni@jidanni.org:
>
>> Signed-off-by: jidanni <jidanni@jidanni.org>
>
> Didn't you mean "Signed-off-by: 積丹尼 <jidanni@jidanni.org>"?
Be nice, they are obviously a bit peculiar about their name/sign-off name :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: 'Theirs' merge between branches on a binary file.
From: Tim Visher @ 2008-12-28 17:14 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <49512E9A.5040902@lsrfire.ath.cx>
On Tue, Dec 23, 2008 at 1:31 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Have you seen msysgit (http://code.google.com/p/msysgit/), the easy
> route to git on Windows? It has all you need to check out and compile
> the latest version of git.
I have seen msysgit. I haven't spent too much time with it mainly
because I'm in denial that I have to work with Windows all day at
work. I'm going to have to look into it I think when I attempt to get
my team onto git in a little less than a month.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: getting started, happy with cmd line on windows [Scanned]
From: Daniel Barkalow @ 2008-12-28 18:39 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D07@ALTMORE-SVR.altmore.local>
On Fri, 26 Dec 2008, Conor Rafferty wrote:
> We want to use git to
> a) archive old versions of our project that have till now had no SCM
> applied
There's actually an importer for this; if you can put all of the old
versions into tar files in the same format and list them in order, you can
use "import-tars.perl", which is in contrib/fast-import in the git source
tree. Of course, using that won't teach you anything about the tools, but
it might be the best way to get the real import done with the least chance
of mistakes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH v2] diff: add option to show context between close hunks
From: René Scharfe @ 2008-12-28 18:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, Davide Libenzi, Johannes Sixt, Junio C Hamano
Merge two hunks if there is only the specified number of otherwise unshown
context between them. For --inter-hunk-context=1, the resulting patch has
the same number of lines but shows uninterrupted context instead of a
context header line in between.
Patches generated with this option are easier to read but are also more
likely to conflict if the file to be patched contains other changes.
This patch keeps the default for this option at 0. It is intended to just
make the feature available in order to see its advantages and downsides.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Changes: s/chunk/hunk/g, bash completion, redone test script.
Documentation/diff-options.txt | 4 ++
contrib/completion/git-completion.bash | 2 +
diff.c | 4 ++
diff.h | 1 +
t/t4032-diff-inter-hunk-context.sh | 92 ++++++++++++++++++++++++++++++++
xdiff/xdiff.h | 1 +
xdiff/xemit.c | 3 +-
7 files changed, 106 insertions(+), 1 deletions(-)
create mode 100755 t/t4032-diff-inter-hunk-context.sh
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index c62b45c..c7fcc80 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -215,6 +215,10 @@ endif::git-format-patch[]
-w::
Shorthand for "--ignore-all-space".
+--inter-hunk-context=<lines>::
+ Show the context between diff hunks, up to the specified number
+ of lines, thereby fusing hunks that are close to each other.
+
--exit-code::
Make the program exit with codes similar to diff(1).
That is, it exits with 1 if there were differences and
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e004549..a046441 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -776,6 +776,7 @@ _git_diff ()
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
--base --ours --theirs
+ --inter-hunk-context=
"
return
;;
@@ -967,6 +968,7 @@ _git_log ()
--color-words --walk-reflogs
--parents --children --full-history
--merge
+ --inter-hunk-context=
"
return
;;
diff --git a/diff.c b/diff.c
index 0484601..56b80f9 100644
--- a/diff.c
+++ b/diff.c
@@ -1469,6 +1469,7 @@ static void builtin_diff(const char *name_a,
ecbdata.file = o->file;
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
+ xecfg.interhunkctxlen = o->interhunkcontext;
xecfg.flags = XDL_EMIT_FUNCNAMES;
if (pe)
xdiff_set_find_func(&xecfg, pe->pattern, pe->cflags);
@@ -2538,6 +2539,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->b_prefix = arg + 13;
else if (!strcmp(arg, "--no-prefix"))
options->a_prefix = options->b_prefix = "";
+ else if (opt_arg(arg, '\0', "inter-hunk-context",
+ &options->interhunkcontext))
+ ;
else if (!prefixcmp(arg, "--output=")) {
options->file = fopen(arg + strlen("--output="), "w");
options->close_file = 1;
diff --git a/diff.h b/diff.h
index 42582ed..4d5a327 100644
--- a/diff.h
+++ b/diff.h
@@ -78,6 +78,7 @@ struct diff_options {
const char *a_prefix, *b_prefix;
unsigned flags;
int context;
+ int interhunkcontext;
int break_opt;
int detect_rename;
int skip_stat_unmatch;
diff --git a/t/t4032-diff-inter-hunk-context.sh b/t/t4032-diff-inter-hunk-context.sh
new file mode 100755
index 0000000..e4e3e28
--- /dev/null
+++ b/t/t4032-diff-inter-hunk-context.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+
+test_description='diff hunk fusing'
+
+. ./test-lib.sh
+
+f() {
+ echo $1
+ i=1
+ while test $i -le $2
+ do
+ echo $i
+ i=$(expr $i + 1)
+ done
+ echo $3
+}
+
+t() {
+ case $# in
+ 4) hunks=$4; cmd="diff -U$3";;
+ 5) hunks=$5; cmd="diff -U$3 --inter-hunk-context=$4";;
+ esac
+ label="$cmd, $1 common $2"
+ file=f$1
+ expected=expected.$file.$3.$hunks
+
+ if ! test -f $file
+ then
+ f A $1 B >$file
+ git add $file
+ git commit -q -m. $file
+ f X $1 Y >$file
+ fi
+
+ test_expect_success "$label: count hunks ($hunks)" "
+ test $(git $cmd $file | grep '^@@ ' | wc -l) = $hunks
+ "
+
+ test -f $expected &&
+ test_expect_success "$label: check output" "
+ git $cmd $file | grep -v '^index ' >actual &&
+ test_cmp $expected actual
+ "
+}
+
+cat <<EOF >expected.f1.0.1 || exit 1
+diff --git a/f1 b/f1
+--- a/f1
++++ b/f1
+@@ -1,3 +1,3 @@
+-A
++X
+ 1
+-B
++Y
+EOF
+
+cat <<EOF >expected.f1.0.2 || exit 1
+diff --git a/f1 b/f1
+--- a/f1
++++ b/f1
+@@ -1 +1 @@
+-A
++X
+@@ -3 +3 @@ A
+-B
++Y
+EOF
+
+# common lines ctx intrctx hunks
+t 1 line 0 2
+t 1 line 0 0 2
+t 1 line 0 1 1
+t 1 line 0 2 1
+t 1 line 1 1
+
+t 2 lines 0 2
+t 2 lines 0 0 2
+t 2 lines 0 1 2
+t 2 lines 0 2 1
+t 2 lines 1 1
+
+t 3 lines 1 2
+t 3 lines 1 0 2
+t 3 lines 1 1 1
+t 3 lines 1 2 1
+
+t 9 lines 3 2
+t 9 lines 3 2 2
+t 9 lines 3 3 1
+
+test_done
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 84fff58..361f802 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -84,6 +84,7 @@ typedef long (*find_func_t)(const char *line, long line_len, char *buffer, long
typedef struct s_xdemitconf {
long ctxlen;
+ long interhunkctxlen;
unsigned long flags;
find_func_t find_func;
void *find_func_priv;
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 4625c1b..05bfa41 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -59,9 +59,10 @@ static int xdl_emit_record(xdfile_t *xdf, long ri, char const *pre, xdemitcb_t *
*/
xdchange_t *xdl_get_hunk(xdchange_t *xscr, xdemitconf_t const *xecfg) {
xdchange_t *xch, *xchp;
+ long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen;
for (xchp = xscr, xch = xscr->next; xch; xchp = xch, xch = xch->next)
- if (xch->i1 - (xchp->i1 + xchp->chg1) > 2 * xecfg->ctxlen)
+ if (xch->i1 - (xchp->i1 + xchp->chg1) > max_common)
break;
return xchp;
--
1.6.1
^ permalink raw reply related
* Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
From: Karl Hasselström @ 2008-12-28 20:49 UTC (permalink / raw)
To: Hannes Eder; +Cc: Catalin Marinas, git
In-Reply-To: <49562413.0437560a.287d.5133@mx.google.com>
On 2008-12-27 13:37:20 +0100, Hannes Eder wrote:
> This allows following usage:
>
> $ stg new full/path/file-fix-foobar
> Now at patch "full-path-file-fix-foobar"
>
> Signed-off-by: Hannes Eder <hannes@hanneseder.net>
> ---
>
> I ran into as a '/' in a patch messed up stgit.
>
> I find this useful as 'stg uncommit' does the same translation.
Clearly, bad path names shouldn't mess anything up -- see
https://gna.org/bugs/?10919
But I would prefer "stg new" to quit with an error message when given
an illegal patch name, not silently mangle it. (Of course, the
commands that generate patch names from commit messages -- such as
"stg new" when not given an explicit patch name -- should mangle the
commit message as much as necessary. But when the user gives us a
patch name, we should either use that as is or fail with an
informative message.)
I think the right thing to do would be to construct a function that
validates patch names (I don't think we have one right now), and then
call it whenever we need to check if a patch name is OK. Such as when
the user gives us the name of a new patch. And when we've
auto-generated a patch name from a commit message, we should probably
assert that that the check function is OK with the name.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: RFE: git-import-dsc should support http-links
From: Rolf Leggewie @ 2008-12-28 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <20081227114910.GA6481@bogon.ms20.nix>
Thanks, guys!
Guido Günther wrote:
>>> PS: How about some kind of official bug tracker for git?
> The Debian BTS (bugs.debian.org) is the official bugtracker for
> git-buildpackage.
http://bugs.debian.org/510036
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-28 22:21 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <20081228114445.GA8511@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> I've been giving this some thought and I would like to propose the following
> solution:
>
> 1. Save index state.
> 2. Merge using whichever strategy, in index only, ignoring work tree.
> This step includes rename detection.
> 3. Check that work tree files match original index, if index does not match
> HEAD. Otherwise abort, restore index and leave everything unchanged.
> 4. Checkout index, overwriting work tree files, and removing files which are
> in HEAD, but not in the index.
> 5. If the merge was clean, commit.
>
> AFAICS, this is largely the behavior right now, except that steps 3 and 4
> are intermingled with step 2, which makes it impossible to abort the merge
> if an untracked file is in the way after rename detection.
The description of step 3 above may be a bit too sketchy and simplistic,
but I agree, provided if you are talking about what merge-recursive
backend does, that is how it ought to do things. The strategy should
instead:
- have trivial merge done inside the index, likely leveraging
unpack_trees() three-way merge mechanism we already have, and it will
allow you to notice and abort upon seeing local modifications in the
work tree at this stage, except for renamed paths;
- notice renames for the unmerged ones and deal with them inside the
index, still without resolving. E.g. in a merge between A and B, if
side A deleted "path1" and created a "path2" that is similar to deleted
"path1", have the ancestor version at stage #1 of "path2", hoist
"path2" of side A to stage #2, and move the version of "path1" from
side B and have it at stage #3 of "path2", which would result in an
index without "path1" in any stage, and "path2" in three stages.
If the other side's rename causes a path to be moved, you can/should
check and notice local modifications to it at this stage.
You can also notice D/F conflict at this phase (e.g. side B in the
above example may have created a new path "path2/file1" and the index
may have stage #3 entry without any other stages for "path2/file1") and
abort.
- try to resolve unmerged paths inside the index.
Because you matched up possible renames and and adjusted the entries,
you can resolve aggressively, e.g. a path with identical stage #1 and
#3 but missing stage #2 results in delete, a path with missing stage #1
and #2 but with stage #3 results in create, etc.
- notice the paths that need to be written out to the work tree. Paths
with local changes should have been noticed already in the above, but
while debugging your new algorithm, you may want to have a logic to
double check so that you won't miss any. Abort if you find any local
change that can be clobbered.
- Then, finally, you commit to writing the results out, both the index
and the work tree. The changes to the work tree may be cleanly merged,
or an unmerged results with three-way conflict markers.
This way, you will never have "merge stops in halfway because it notices
it will clobber a local change too late after it has already written a
partial merge results to the work tree" problem, I think.
> git merge <branch>
> # Conflicts? I don't have time for that now.
> git reset --hard HEAD
>
> under all circumstances, without touching any untracked files.
Even though I agree the above without the second line is a good thing to
have, I think your description is a wrong way to present the desirable
goal.
"Conflicts?" is an indication that you had a lot of other things going on
inside your work tree as set of local changes that you "don't have time
for that now", and "reset --hard" is a sure way to lose them. You
shouldn't train your users to say "--hard" lightly.
The issue of unreliable D/F conflict detection and local change detection
the current merge-recursive has at its corner case is not about
"Conflicts? I don't have time for that now" at all. It is not about " I
had something precious in my work tree, but the merge turned out to be
unmanageable for me", either.
The issue is about "Crap, if merge has to abort in the middle because it
has to refrain from writing out a half-merged state out, not to overwrite
my local changes, it shouldn't have written out anything else to the work
tree at all. Don't abort in the middle but abort upfront without touching
my work tree!".
I think the correct statement of the goal is:
$ git merge ..
# Ah, I have "path2" locally modified so it cannot proceed?
# I did not lose anything, nor it did anything to my index nor
# work tree. Good.
By this, you realize that you should wrap up what you have been doing
first, because the above is an indication that other end has made some
overlapping changes. You can either (1) decide not to merge at this point
because you are not ready, keep working on what you were doing first and
later merge, or (2) stash away what you have been doing and do the merge
first, and then unstash.
^ permalink raw reply
* [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Markus Heidelberg @ 2008-12-28 23:37 UTC (permalink / raw)
To: gitster; +Cc: git
This variable was added in 5f8b9fc (git-send-email: add a new
sendemail.cc configuration variable, 2008-04-27), but is not yet refered
to by the documentation.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-send-email.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index b69846e..ff4aeff 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -34,6 +34,7 @@ The --bcc option must be repeated for each user you want on the bcc list.
--cc::
Specify a starting "Cc:" value for each email.
+ Default is the value of 'sendemail.cc'.
+
The --cc option must be repeated for each user you want on the cc list.
--
1.6.1.21.g0298
^ permalink raw reply related
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-28 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <7v3ag89c0b.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 28, 2008 at 02:21:40PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > I've been giving this some thought and I would like to propose the following
> > solution:
> >
> > 1. Save index state.
> > 2. Merge using whichever strategy, in index only, ignoring work tree.
> > This step includes rename detection.
> > 3. Check that work tree files match original index, if index does not match
> > HEAD. Otherwise abort, restore index and leave everything unchanged.
> > 4. Checkout index, overwriting work tree files, and removing files which are
> > in HEAD, but not in the index.
> > 5. If the merge was clean, commit.
> >
> > AFAICS, this is largely the behavior right now, except that steps 3 and 4
> > are intermingled with step 2, which makes it impossible to abort the merge
> > if an untracked file is in the way after rename detection.
>
> The description of step 3 above may be a bit too sketchy and simplistic,
> but I agree, provided if you are talking about what merge-recursive
> backend does, that is how it ought to do things. The strategy should
> instead:
Actually, I was hoping to find a solution that's independent of the merge
strategy. I think the merge strategy should not have to concern itself with
the work tree at all.
Regarding my description of step 3, I worded it carefully to cover all
cases. My assumption at this stage is that the merge strategy took care not
to overwrite any staged changes, unless the merge is trivial. It is
therefore safe to overwrite the work tree file if it matches either the
original index, or HEAD.
> - have trivial merge done inside the index, likely leveraging
> unpack_trees() three-way merge mechanism we already have, and it will
> allow you to notice and abort upon seeing local modifications in the
> work tree at this stage, except for renamed paths;
Right, but why would we want to do it this early? Is there a performance
issue? If not, I argue that we don't care about the work tree at this stage.
Only the end result matters.
> - notice renames for the unmerged ones and deal with them inside the
> index, still without resolving. E.g. in a merge between A and B, if
> side A deleted "path1" and created a "path2" that is similar to deleted
> "path1", have the ancestor version at stage #1 of "path2", hoist
> "path2" of side A to stage #2, and move the version of "path1" from
> side B and have it at stage #3 of "path2", which would result in an
> index without "path1" in any stage, and "path2" in three stages.
Right. So in this case we do not abort if "path1" had unstaged
changes, because "path1" of B was moved to "path2" anyways. Conversely, if
"path2" had unstaged changes, we do abort, because it would be overwritten
by the merge (or conflict resolution). All this can be decided without any
knowledge about detected renames or the merge strategy used.
> If the other side's rename causes a path to be moved, you can/should
> check and notice local modifications to it at this stage.
>
> You can also notice D/F conflict at this phase (e.g. side B in the
> above example may have created a new path "path2/file1" and the index
> may have stage #3 entry without any other stages for "path2/file1") and
> abort.
>
> - try to resolve unmerged paths inside the index.
>
> Because you matched up possible renames and and adjusted the entries,
> you can resolve aggressively, e.g. a path with identical stage #1 and
> #3 but missing stage #2 results in delete, a path with missing stage #1
> and #2 but with stage #3 results in create, etc.
This should be done before checking for D/F conflicts. If a file ends up
getting removed, the D/F conflict is avoided.
> - notice the paths that need to be written out to the work tree. Paths
> with local changes should have been noticed already in the above, but
> while debugging your new algorithm, you may want to have a logic to
> double check so that you won't miss any. Abort if you find any local
> change that can be clobbered.
>
> - Then, finally, you commit to writing the results out, both the index
> and the work tree. The changes to the work tree may be cleanly merged,
> or an unmerged results with three-way conflict markers.
>
> This way, you will never have "merge stops in halfway because it notices
> it will clobber a local change too late after it has already written a
> partial merge results to the work tree" problem, I think.
Right. So all we have to do is keep unpack_trees() and process_entry() in
merge_trees() from writing to the work tree and delay until after
try_merge_strategy() has completed. Then we check for D/F conflicts and
dirty work tree files before finally checking out the merge result.
Thinking about this now, I wonder what happens if recursive merge has a D/F
conflict in one of its recursions. There is nothing smart it can do, so it
could continue with a D/F conflict in the index, hoping that it goes away in
the final result. So again, D/F conflicts should not matter for the merge
strategy.
> > git merge <branch>
> > # Conflicts? I don't have time for that now.
> > git reset --hard HEAD
> >
> > under all circumstances, without touching any untracked files.
>
> Even though I agree the above without the second line is a good thing to
> have, I think your description is a wrong way to present the desirable
> goal.
[...]
> The issue is about "Crap, if merge has to abort in the middle because it
> has to refrain from writing out a half-merged state out, not to overwrite
> my local changes, it shouldn't have written out anything else to the work
> tree at all. Don't abort in the middle but abort upfront without touching
> my work tree!".
Point taken.
^ 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