* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-18 2:43 UTC (permalink / raw)
To: git
In-Reply-To: <200912170800.35752.robin.rosenberg@dewire.com>
Robin Rosenberg writes:
> tisdag 15 december 2009 23:24:15 skrev David Antliff:
> > The problem is that sometimes, after a git-clone, the output of git-status
> > and git-diff shows entire files as being different. However these files
> > have not been modified by the user - only git has had a chance to change
> > them (due to autocrlf=true). But surely if git has converted the file
> > automatically, it should know that it has to compensate for this when
> > comparing with the local repository?
>
> AFAIK, this happens if you have CRLF line endings in the blobs in the repo.
Oh? That could very well be true - how would such line endings get into a blob?
I'm pretty sure everyone is using autocrlf=true which should convert all line
endings to LF on commit, but perhaps there's another way to get CRLF line
endings into a blob?
If autocrlf=false, files are committed as-is (I believe), so this would be one
way to end up committing such files. But as far as I know, nobody has turned
that option off in our group.
^ permalink raw reply
* Re: how can I push a sub-tree
From: Zhi Li @ 2009-12-18 2:05 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <2986b3940912171655t397f90b2tf28bac3555181292@mail.gmail.com>
Hi,
I found a way to do it, but I do not know whether it is the simplest.
In master branch, run "git cat-file -p" several times to find rack
sub-tree sha. Then check-out branch "rack_branch", run "git read-tree
sha". The sha is that one just get by "git cat-file -p". Finally,
git-commit, git-push...
Cheers,
Zhi
On Fri, Dec 18, 2009 at 8:55 AM, Zhi Li <lizhi1215@gmail.com> wrote:
> Hi,
>
> Not sub-module, but sub-tree.
>
> My problems are:
> $ git remote add rack_remote git@github.com:schacon/rack.git
> $ git fetch rack_remote
> $ git branch rack_branch rack_remote/master
> $ git read-tree --prefix=rack/ -u rack_branch
>
> Now in master branch, I have a sub-tree rack. Later I modified
> something in rack sub-tree. Then, how could I push my changes to
> rack_remote?
>
> Thanks
> Zhi
>
> On Thu, Dec 17, 2009 at 6:14 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Dec 17, 2009 at 5:50 PM, Zhi Li <lizhi1215@gmail.com> wrote:
>>> I tried to find a way to push a sub-tree. In section 6.7 of "Pro Git",
>>> there's a way for pulling a git sub-tree. But I have not found the
>>> opposite: push a git sub-tree. Can someone help me?
>>
>> I've not read the book, but perhaps you mean submodules?
>>
>> If so, refer to the part in the git submodule tutorial that describes
>> how to make changes within a submodule on the GitWiki at
>> http://git.or.cz/gitwiki/GitSubmoduleTutorial.
>>
>> --
>> Cheers,
>> Ray Chuan
>>
>
^ permalink raw reply
* Re: how can I push a sub-tree
From: Zhi Li @ 2009-12-18 0:55 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0912170214u433769e3ucf8180022aa72fb3@mail.gmail.com>
Hi,
Not sub-module, but sub-tree.
My problems are:
$ git remote add rack_remote git@github.com:schacon/rack.git
$ git fetch rack_remote
$ git branch rack_branch rack_remote/master
$ git read-tree --prefix=rack/ -u rack_branch
Now in master branch, I have a sub-tree rack. Later I modified
something in rack sub-tree. Then, how could I push my changes to
rack_remote?
Thanks
Zhi
On Thu, Dec 17, 2009 at 6:14 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hi,
>
> On Thu, Dec 17, 2009 at 5:50 PM, Zhi Li <lizhi1215@gmail.com> wrote:
>> I tried to find a way to push a sub-tree. In section 6.7 of "Pro Git",
>> there's a way for pulling a git sub-tree. But I have not found the
>> opposite: push a git sub-tree. Can someone help me?
>
> I've not read the book, but perhaps you mean submodules?
>
> If so, refer to the part in the git submodule tutorial that describes
> how to make changes within a submodule on the GitWiki at
> http://git.or.cz/gitwiki/GitSubmoduleTutorial.
>
> --
> Cheers,
> Ray Chuan
>
^ permalink raw reply
* Re: [PATCH 1/2] api-strbuf.txt: fix typos and document launch_editor()
From: Miklos Vajna @ 2009-12-18 0:42 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1261094729-24128-1-git-send-email-bebarino@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
On Thu, Dec 17, 2009 at 04:05:28PM -0800, Stephen Boyd <bebarino@gmail.com> wrote:
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
> Documentation/technical/api-strbuf.txt | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
Thanks, I really should have read these sentences once again before
sending them in. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] am: fix patch format detection for Thunderbird "Save As" emails
From: Junio C Hamano @ 2009-12-18 0:15 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1261094299-22930-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> I'm not sure how portable \r in a sed invocation is.
Not very portable.
Adding
tr -d '\015' <"$1" |
in front of the original "sed" invocation might be a better choice.
> but seems necessary because check_patch_format() is called before any
> splitting with mailsplit is done (where I assume the fix for the issue
> will be done).
I agree that the way non-native mbox format was bolted onto "am" is
somewhat unfortunate.
^ permalink raw reply
* Re: [RFC/PATCH] branch: new option --will-track
From: Junio C Hamano @ 2009-12-18 0:07 UTC (permalink / raw)
To: Dave Olszewski; +Cc: git
In-Reply-To: <1260956399-13802-1-git-send-email-cxreg@pobox.com>
Dave Olszewski <cxreg@pobox.com> writes:
> A common question from users creating branches in an environment where
> they intend to push the branch to a shared bare repository, and then
> later pull commits from upstream into the branch that they initially
> created, is how do they create the branch with this tracking info
> already set up.
We try reasonably hard not to force users to make a decision before it
gets absolutely necessary [*1*]. This option seems to only help users who
can decide upfront upon "git branch" time if the branch is worth sharing
with others and if the name of the branch will be the final one, and
people who forget to give this new option when they ran "git branch", or
those who changed their mind as to what the newly created branch with this
option should interact with, will still need to use "git config" to update
the settings.
Not very nice, not because it solves only a part of the problem, but
because it force users to decide early and not change their mind.
Instead perhaps we would want to add an option to retarget an existing
branch any time the user wants, e.g. "git branch --reconfigure"? Once we
have such an option, people who *can* decide upfront can use that feature
when creating a new branch at the same time.
Also "git pull --remember $there $this" might be a good way to tell the
configuration mechanism from the UI to remember that "I always want to
merge $this branch from $there while on the branch I am currently on", and
its implementation may probably use "git branch --reconfigure" internally.
Having said all that, I am not very interested in topics on the mechanism
that updates or uses these variables, as I tend to avoid relying on them
myself, and instead teach people to spell them out (which seems to foster
better understanding of what goes on, with reduced user confusion).
Hence, I wouldn't claim I have thought things through in this area, and
the above is just me thinking aloud [*2*].
[Footnote]
*1* There are ample examples, ranging from detached HEAD (you do not have
to decide if the experiment you are going to do deserves a separate branch
to store the result permanently) to the separation between commit and push
(what you commit does not have to be perfect and you have a chance to tidy
them up before publishing).
*2* IOW don't take my "I am not interested" as "patches in this area have
little chance of getting applied."
^ permalink raw reply
* [PATCH 2/2] technical-docs: document hash API
From: Stephen Boyd @ 2009-12-18 0:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1261094729-24128-1-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/technical/api-hash.txt | 50 ++++++++++++++++++++++++++++++++-
1 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt
index c784d3e..e5061e0 100644
--- a/Documentation/technical/api-hash.txt
+++ b/Documentation/technical/api-hash.txt
@@ -1,6 +1,52 @@
hash API
========
-Talk about <hash.h>
+The hash API is a collection of simple hash table functions. Users are expected
+to implement their own hashing.
-(Linus)
+Data Structures
+---------------
+
+`struct hash_table`::
+
+ The hash table structure. The `array` member points to the hash table
+ entries. The `size` member counts the total number of valid and invalid
+ entries in the table. The `nr` member keeps track of the number of
+ valid entries.
+
+`struct hash_table_entry`::
+
+ An opaque structure representing an entry in the hash table. The `hash`
+ member is the entry's hash key and the `ptr` member is the entry's
+ value.
+
+Functions
+---------
+
+`init_hash`::
+
+ Initialize the hash table.
+
+`free_hash`::
+
+ Release memory associated with the hash table.
+
+`insert_hash`::
+
+ Insert a pointer into the hash table. If an entry with that hash
+ already exists, a pointer to the existing entry's value is returned.
+ Otherwise NULL is returned. This allows callers to implement
+ chaining, etc.
+
+`lookup_hash`::
+
+ Lookup an entry in the hash table. If an entry with that hash exists
+ the entry's value is returned. Otherwise NULL is returned.
+
+`for_each_hash`::
+
+ Call a function for each entry in the hash table. The function is
+ expected to take the entry's value as its only argument and return an
+ int. If the function returns a negative int the loop is aborted
+ immediately. Otherwise, the return value is accumulated and the sum
+ returned upon completion of the loop.
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* [PATCH 1/2] api-strbuf.txt: fix typos and document launch_editor()
From: Stephen Boyd @ 2009-12-18 0:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/technical/api-strbuf.txt | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index 7438149..a0e0f85 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -12,7 +12,7 @@ strbuf API actually relies on the string being free of NULs.
strbufs has some invariants that are very important to keep in mind:
-. The `buf` member is never NULL, so you it can be used in any usual C
+. The `buf` member is never NULL, so it can be used in any usual C
string operations safely. strbuf's _have_ to be initialized either by
`strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
+
@@ -55,7 +55,7 @@ Data structures
* `struct strbuf`
-This is string buffer structure. The `len` member can be used to
+This is the string buffer structure. The `len` member can be used to
determine the current length of the string, and `buf` member provides access to
the string itself.
@@ -253,3 +253,9 @@ same behaviour as well.
comments are considered contents to be removed or not.
`launch_editor`::
+
+ Launch the user preferred editor to edit a file and fill the buffer
+ with the file's contents upon the user completing their editing. The
+ third argument can be used to set the environment which the editor is
+ run in. If the buffer is NULL the editor is launched as usual but the
+ file's contents are not read into the buffer upon completion.
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* [PATCH] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-17 23:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header field names. The headers are always
separated from the message body with a blank line. When Thunderbird3 saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
---
I'm not sure how portable \r in a sed invocation is. Perhaps just checking
that l1, l2, and l3 are rfc2822 header fields (or indented lines) is better
than trying to check all of the headers?
This seems related to
am fails to apply patches for files with CRLF lineendings
http://article.gmane.org/gmane.comp.version-control.git/135229
but seems necessary because check_patch_format() is called before any
splitting with mailsplit is done (where I assume the fix for the issue
will be done).
git-am.sh | 2 +-
t/t4150-am.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4838cdb..bb106b7 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -204,7 +204,7 @@ check_patch_format () {
# discarding the indented remainder of folded lines,
# and see if it looks like that they all begin with the
# header field names...
- sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
+ sed -n -e '/^\r*$/q' -e '/^[ ]/d' -e p "$1" |
sane_egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..578bc81 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -83,6 +83,12 @@ test_expect_success setup '
echo "X-Fake-Field: Line Three" &&
git format-patch --stdout first | sed -e "1d"
} > patch1.eml &&
+ {
+ echo "X-Fake-Field: Line One" &&
+ echo "X-Fake-Field: Line Two" &&
+ echo "X-Fake-Field: Line Three" &&
+ git format-patch --stdout first | sed -e "1d"
+ } | sed -e "s/$/\r/" > patch1-crlf.eml &&
sed -n -e "3,\$p" msg >file &&
git add file &&
test_tick &&
@@ -123,6 +129,15 @@ test_expect_success 'am applies patch e-mail not in a mbox' '
test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
'
+test_expect_success 'am applies patch e-mail not in a mbox with CRLF' '
+ git checkout first &&
+ git am patch1-crlf.eml &&
+ ! test -d .git/rebase-apply &&
+ test -z "$(git diff second)" &&
+ test "$(git rev-parse second)" = "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
+'
+
GIT_AUTHOR_NAME="Another Thor"
GIT_AUTHOR_EMAIL="a.thor@example.com"
GIT_COMMITTER_NAME="Co M Miter"
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-17 23:22 UTC (permalink / raw)
To: git; +Cc: Gustav Hållberg, Karl Wiberg
StGit commands resulting in a conflicting patch pushing record two
transactions in the log (with one of them being inconsistent with HEAD
!= top). Undoing such operations requires two "stg undo" (possibly with
--hard) commands which is unintuitive. This patch changes such
operations to only record one log entry and "stg undo" reverts the stack
to the state prior to the operation.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Cc: Gustav Hållberg <gustav@virtutech.com>
Cc: Karl Wiberg <kha@treskal.com>
---
stgit/lib/transaction.py | 5 +++--
t/t3103-undo-hard.sh | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 30a153b..fad5ab4 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -232,8 +232,9 @@ class StackTransaction(object):
self.__stack.patchorder.hidden = self.__hidden
log.log_entry(self.__stack, msg)
old_applied = self.__stack.patchorder.applied
- write(self.__msg)
- if self.__conflicting_push != None:
+ if not self.__conflicting_push:
+ write(self.__msg)
+ else:
self.__patches = _TransPatchMap(self.__stack)
self.__conflicting_push()
write(self.__msg + ' (CONFLICT)')
diff --git a/t/t3103-undo-hard.sh b/t/t3103-undo-hard.sh
index 2d0f382..df14b1f 100755
--- a/t/t3103-undo-hard.sh
+++ b/t/t3103-undo-hard.sh
@@ -46,11 +46,11 @@ test_expect_success 'Try to undo without --hard' '
cat > expected.txt <<EOF
EOF
-test_expect_failure 'Try to undo with --hard' '
+test_expect_success 'Try to undo with --hard' '
stg undo --hard &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
- test "$(echo $(stg series))" = "> p1 - p2 - p3" &&
+ test "$(echo $(stg series))" = "+ p1 + p2 > p3" &&
test "$(stg id)" = "$(stg id $(stg top))"
'
^ permalink raw reply related
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Junio C Hamano @ 2009-12-17 22:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Bernhard R. Link, git
In-Reply-To: <4B29106C.1040501@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
>
> Bernhard R. Link schrieb:
>> --prune-tree makes rev-list without paths equivalent to
>> "git rev-list $options -- ." (or .. or ../.. and so on,
>> if you are in some subdirectory).
>> This is the new default for format-patch and rebase
>
> Why do you need a new option when you can just add "-- ." to the rev-list
> invocation?
I agree that --[no-]prune-tree options are unnecessary. The patch to
builtin-log.c, the second hunk to revision.c, and revision.h would be
sufficient and all others should be dropped. Instead, the shell script
Porcelains can simply add "-- ." at the end of their rev-list invocations.
That way, we don't have to add anything to the documentation either.
But I wonder if it is an indication of something screwy in the workflow,
if a branch that merges others with "-s ours" is where the patches for
upstream submission is taken from with format-patch, or what is rebased
and internally gets its patches extracted with format-patch.
A branch that merges with "-s ours" is typically done so that others can
pull and build against (and "-s ours" is used to cauterize the history of
a bad side branch), and good bits merged into it would also have come from
a different clean branch that is merged into that branch. It might make
more sense to format-patch that clean branch when preparing for upstream
submission, than the "aggregated mesh of commits" branch with "-s ours"
fix-ups.
On the other hand, a branch that will be rebased to keep up with others is
by definition private, and I don't see a reason to mark with "-s ours" to
cauterize history of an unrelated side branch that tried to do something
similar to what the branch is trying to achieve in that setting. You can
instead ignore such a side branch and not merge with it. So I don't know
how a sane history you are going to rebase ends up containing a "-s ours"
merge to begin with.
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-17 21:48 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <4B2A1895.2000803@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> [091217 12:40]:
> > I want the default for format-patch changed.
>
> I do not see why format-patch would have to be changed. The case that you
> outline (a merge -s ours happened and you want to follow only one parent)
> is rare enough
While it is rare, the result format-patch currently produces is quite a
desaster without any need.
> and even more rarly will somebody want to apply format-patch to such a history.
> But I guess that you are actually not interested in format-patch per se,
> but rather in rebase (which uses format-patch).
I'm looking for a nice way to store the history of a patches in a Debian package.
Currently the best way is to use quilt and store the patches in git.
Topgit is quite overkill, git directly preserving history means no way to
export sane patches. And git rebase -i means losing history of previous
states and pullability.
An way to combine those is doing many trivial merges, but that kills
rebase and format-patch. (While the patch exporting for creating the
debian source packages could change to the right directory and give the
proper arguments, needing to remember the extra argument and teaching
anyone else involved how to call it to get what to sent to upstream
is annoying).
> I haven't looked at the code, but wouldn't it be matter of "if we do not
> have any pathspec, add '.'" *after* all options are parsed?
That's what I would say my patch is doing.
> git rev-list -- . works in a bare repository, too. If you hard-code "-- ."
> in the rev-list invocations in git-rebase[--interactive], then it cannot
> be said that this works "by chance" due to cd_to_toplevel.
It works in a bare repository. But it does not work when called from a
subdirectory of the working dir.
The easiest way I see to express generally
git rev-list --prune-tree $args
is
topdir=$(git rev-parse --show-cdup)
if test -z "$topdir" ; then
topdir=.
fi
set -- $args
while test $# -gt 0 ; do
if test "x$1" = "x--" ; then
break
fi
shift
done
if test $# -gt 1 ; then
git rev-list $args
elif test $# -eq 1 ; then
git rev-list $args $topdir
else
git rev-list $args -- $topdir
fi
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Jakub Narebski @ 2009-12-17 21:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0912171241j56ecd2f1y3dc66cf3b86bd784@mail.gmail.com>
Giuseppe Bilotta wrote:
> 2009/12/17 Jakub Narebski <jnareb@gmail.com>:
>> On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
[...]
>>> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
>>> + my $has_merges = !grep(/^--no-merges$/, @extra_options);
>>> +
>>
>> Wouldn't it be better to use straight
>>
>> + my $no_merges = grep(/^--no-merges$/, @extra_options);
>>
>> Because $has_merges is true also for example for 'tree' view... which
>> absolutely doesn't make any sense whatsoever.
>
> The reason why I have two vars is that one checks if we care about the
> option, and the other is to see if it's enabled or not. We don't want
> the 'show merges' toggle to appear in view which don't handle the
> --no-merge option.
Perhaps I didn't made myself clear.
What I wanted to ask is to switch $has_merges to $no_merges, not to remove
$can_have_merges. Its a question of semantics of $has_merges, which do not
mean that action has (handles) merges.
This is of course the question of style, but I think this would make code
more maintainable.
Of course if you go %extra_options hash route this issue wouldn't matter.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Giuseppe Bilotta @ 2009-12-17 20:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200912171637.45810.jnareb@gmail.com>
2009/12/17 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
>> This is something I've been wanting for a while. There are a number of
>> things that don't 'click' with this proof of concept, and I'm coming to
>> the list to hear the opinion of users and developers on how to improve
>> the thing.
>>
>> The patch is live at http://git.oblomov.eu/, an example affected page is
>> http://git.oblomov.eu/git/shortlog
>
> You should tell here that one must put mouse over main header (the one
> with 'projects / project / action' breadcrumbs) for the new link to be
> visible... because I was wondering where is this new link.
I mentioned it right below, but I do realize that people might have
gone looking for it before reading further down ;-)
>> Things that are sure to change:
>>
>> * the aesthetics and location of the toggle link (it shows on mousehover
>> in the title).
>
> It is not only the question where to put link, but also where to put
> the *code* (where the code should belong to).
>
> At first I thought: WTF? Why the feature that deals with log-like views
> is put in very generic and common for all actions/views git_header_html
> subroutine? Especially after change that made all loglike views use
> common infrastructure of git_log_generic.
>
> But then I realized that it is specific example of *generic* feature
> that deals with extra_options... which admittedly is currently limited
> to '--no-merges' only. So if it is put in git_header_html, then all
> views with HTML output (which does not include 'atom' and 'rss' actions,
> but which actions IIRC have their own handling of '--no-merges')
> which have support for extra_options would have ability to turn them
> on and off.
Exactly. Although the code as it is now is not really flexible enough
to handle other cases. I see further down a couple of your ideas would
make this kind of thing more extensible.
> What you need to add (if this link is to be in git_header_html) is
> to create links only when $status == 200, because otherwise the link
> would be present also for error pages, which I think is wrong.
Good point. That's an easy fix too 8-)
>> Other options I've considered are:
>> + next to pagination (first | prev | next), either before or after
>> the existing entries
>
> This would fit with the fact that sometimes present "patches" link is on
> the line with pagination links, after pagination links.
>
> But this secondary navigation bar is about other views, and extra_options
> is about modifying current view, and functions more like toggles. OTOH
> we have such toggle for 'blame' <-> 'blame_incremental' switch in
> secondary navigation bar.
Well, at least for this particular option the toggle is closer in
concept to pagination (which also modifies the 'current' view, in a
way).
> Also this would mean that each view type would have to handle extra_options
> itself, as secondary navigation bar is very much action-specific. Not
> that it matters now, with only single '--no-merges' option supported.
Even with more options, I have half an idea on how to refactor this
handling in a way that should make it easy for views to handle the
extra options.
>> + on mouseover for the table section that refers to the (short)log;
>> this would make it possible to put it summary view too, for example
>
> This would mean having link inside link, as those headers in summary view
> functions as link to 'shortlog' view (quite useful I think), and to the
> project summary in the 'shortlog' view itself (I'm not sure how useful
> that is). We already have problems with ref markers being links inside
> links and having broken layout in some strict XHTML conformance browsers.
(I still think that prohibiting link-in-link is idiotic, but this is
not the place where this should be discussed)
> In short: I am not sure what would be the best solution. Nevertheless
> I think that link should be more visible, and perhaps more toggle-like.
I'll see if I can cook something up.
>> * if you toggle merge view when not on the first page, the reference
>> (first) commit in the view is likely to change drastically, which
>> causes confusion. I have not found a satisfactory solution for this,
>> since the obvious way to 'lock' the view (start paginating from the
>> current top commit) prevents prev/next navigation
>
> Alternate solution would be to clean page (start from 0th page) when
> changing to '--no-merges'.
>
> You would probably need something like 'skip' option, with number of
> commits, not number of pages to skip, and/or 'skip_to' which takes
> commit-id. But i have not thought about this much...
IIRC the log code uses pagination the way it is now because that
reflects the git log works. This would make a different approach more
time consuming on the script part.
>> +
>> +*:hover > span.merge_toggle a { visibility:visible }
>
> I'd rather not have this rule to have different style, i.e. not all
> in single line. Unless it is for RFC only...
I can make it more like the others.
>> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
>> + my $has_merges = !grep(/^--no-merges$/, @extra_options);
>> +
>
> Wouldn't it be better to use straight
>
> + my $no_merges = grep(/^--no-merges$/, @extra_options);
>
> Because $has_merges is true also for example for 'tree' view... which
> absolutely doesn't make any sense whatsoever.
The reason why I have two vars is that one checks if we care about the
option, and the other is to see if it's enabled or not. We don't want
the 'show merges' toggle to appear in view which don't handle the
--no-merge option.
> In more generic solution (which could be perhaps put in a separate commit)
> it could be:
>
> + my %extra_options = map { $_ => 0 } keys %$allowed_options;
> + $extra_options{$_} = 1 foreach @extra_options;
>
> which means that %extra_options is hash which keys are allowed options,
> and which has true value for allowed option which is actually used.
I like this approach. It's also easier to extend to other options, if
and when we'll have them.
I'll try to roll out a new patch with a cleaner design and taking your
suggestions into considerations
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: diff attribute ignored by show and log -p
From: Jeff King @ 2009-12-17 20:24 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nanako Shiraishi, git
In-Reply-To: <76718490912170844i7d5f25d1hc32590b877dbf295@mail.gmail.com>
On Thu, Dec 17, 2009 at 11:44:16AM -0500, Jay Soffian wrote:
> > The need to give --ext-diff is mentioned in 72909be (Add diff-option
> > --ext-diff, 2007-06-30) but its log message doesn't 'explain' why external
> > diff isn't used by default and you need to pass that extra option.
>
> "To prevent funky games with external diff engines, git-log and
> friends prevent external diff engines from being called."
>
> Seemed reason enough to me.
I don't remember discussing it at that time, but much later when
touching the external diff code and adding textconv, Junio and I came to
the conclusion that textconv was reasonable to do as part of "git log
-p", as the result is just an internal conversion that still results in
a text diff. Whereas an external diff might be terribly confusing, as it
could be spawning graphical viewers or producing output which does not
match well with the log output.
> > Probably --ext-diff should be the default?
>
> Or available via a config option anyway.
If you were going to do such a config option, it might make sense to
make it an attribute of the diff driver rather than a global "use
external diff". Then each diff driver could say "Yes, I am reasonable to
be run as part of log -p".
-Peff
^ permalink raw reply
* Re: git svn mkdirs ignores compressed unhandled.log files
From: Eric Wong @ 2009-12-17 20:08 UTC (permalink / raw)
To: Robert Zeh; +Cc: git
In-Reply-To: <8BB233FB-4269-4B14-8703-A4FF1E25FB0D@gmail.com>
Robert Zeh <robert.a.zeh@gmail.com> wrote:
> It looks like there is a conflict between git svn gc and git svn
> mkdirs. The git svn mkdirs command only looks at unhandled.log files.
> Shouldn't it also look at any compressed unhandled.log files too?
Hi Robert,
Yes, an oversight. Does this patch work for you? (Highly untested)
Would you mind writing a test case, been a bit busy with other stuff.
Thanks.
diff --git a/git-svn.perl b/git-svn.perl
index a4b052c..d362de7 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2740,21 +2740,44 @@ sub do_fetch {
sub mkemptydirs {
my ($self, $r) = @_;
+
+ sub scan {
+ my ($r, $empty_dirs, $line) = @_;
+ if (defined $r && $line =~ /^r(\d+)$/) {
+ return 0 if $1 > $r;
+ } elsif ($line =~ /^ \+empty_dir: (.+)$/) {
+ $empty_dirs->{$1} = 1;
+ } elsif ($line =~ /^ \-empty_dir: (.+)$/) {
+ my @d = grep {m[^\Q$1\E(/|$)]} (keys %$empty_dirs);
+ delete @$empty_dirs{@d};
+ }
+ 1; # continue
+ };
+
my %empty_dirs = ();
+ my $gz_file = "$self->{dir}/unhandled.log.gz";
+ if (-f $gz_file) {
+ if (!$can_compress) {
+ warn "Compress::Zlib could not be found; ",
+ "empty directories in $gz_file will not be read\n";
+ } else {
+ my $gz = Compress::Zlib::gzopen($gz_file, "rb") or
+ die "Unable to open $gz_file: $!\n";
+ my $line;
+ while ($gz->gzreadline($line) > 0) {
+ scan($r, \%empty_dirs, $line) or last;
+ }
+ $gz->gzclose;
+ }
+ }
- open my $fh, '<', "$self->{dir}/unhandled.log" or return;
- binmode $fh or croak "binmode: $!";
- while (<$fh>) {
- if (defined $r && /^r(\d+)$/) {
- last if $1 > $r;
- } elsif (/^ \+empty_dir: (.+)$/) {
- $empty_dirs{$1} = 1;
- } elsif (/^ \-empty_dir: (.+)$/) {
- my @d = grep {m[^\Q$1\E(/|$)]} (keys %empty_dirs);
- delete @empty_dirs{@d};
+ if (open my $fh, '<', "$self->{dir}/unhandled.log") {
+ binmode $fh or croak "binmode: $!";
+ while (<$fh>) {
+ scan($r, \%empty_dirs, $_) or last;
}
+ close $fh;
}
- close $fh;
my $strip = qr/\A\Q$self->{path}\E(?:\/|$)/;
foreach my $d (sort keys %empty_dirs) {
--
Eric Wong
^ permalink raw reply related
* Re: adding additional remote refs to a remote repo
From: Junio C Hamano @ 2009-12-17 18:19 UTC (permalink / raw)
To: Peter Petrakis; +Cc: git
In-Reply-To: <a422b4da0912170943q2613faeao208eaa674d1a0afa@mail.gmail.com>
Peter Petrakis <peter.petrakis@gmail.com> writes:
> Now if I push this drbd-8.2.7-merge-branch to the central repo, the next
> guy won't know for sure what this was tracking. I also don't want to
> have to 'add remote ...' every time I clone a new copy. Thanks.
The kind of information you listed above are kept in $GIT_DIR/config of
each repository. This file is kept private to each repository, i.e. not
cloned, fetched or pushed across repositories [*1*].
This is a deliberate design decision.
- The file records mostly personal preferences, e.g. how user works with
his branches in the repository, if the integration is done via rebase
instead of merge, how the output is colored, etc. Your colleagues can
and will use branches other than the ones that may be publicly shared
(like drbd-8.2.7-merge-branch), and how they use their private branches
is not something you want to dictate nor interfere with.
- The [remote "foo"] sections and friends (e.g. [branch "bar"]) in the
"$GIT_DIR/config" in that bare repository you created specifies how
that particular repository interacts with the remote named "foo" and
how branch "bar" is integrated with other things. These may not
necessarily match, and if you are using it as a middleman repository
between your developers and the project upstream, they will in general
not match, the setting the developer repositories want to use. This
should be obvious if you think about where remote.origin.url should
point at. In the middleman repository, you would want "git fetch"
without "origin" to slurp from the upstream and in the developer clones
of this repository, you would want to "git fetch" to update from this
middleman repository.
- The file can has pointers to external programs to be used as filters;
blindly copying it upon clone has security implications as well.
[Footnote]
*1* Often people use README-like document in-tree to tell developers about
the specific settings the project wants them to use (i.e. "how to work
with this project"), together with coding styles, submission guidelines,
etc., that are not tied to the use of git.
^ permalink raw reply
* adding additional remote refs to a remote repo
From: Peter Petrakis @ 2009-12-17 17:43 UTC (permalink / raw)
To: git
I'm setting up a remote repo to aggregate some development which spans
multiple git trees. So I have a bare repo setup using gitosis that I can happily
commit to. I've added the entries directly to the config on the server...
-sh-3.2$ ls
branches config description git-daemon-export-ok HEAD hooks info
objects refs
-sh-3.2$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "drbd-8.2"]
url = git://git.drbd.org/drbd-8.2.git
fetch = +refs/heads/*:refs/remotes/drbd-8.2/*
but when I clone the repo, the remote doesn't show up. What am I doing wrong?
I can easily add the remotes in my local copy and work with the
product. The problem
is that we're tracking this upstream project and need to manage
multiple versions of
it to serve past releases. So in my case the branches will directly
track the upstream
development + any changes we need and then be merged into master.
For example in my local clone.
[remote "drbd-8.2"]
url = git://git.drbd.org/drbd-8.2.git
fetch = +refs/heads/*:refs/remotes/drbd-8.2/*
[branch "drbd-8.2.7-merge-branch"]
remote = drbd-8.2
merge = refs/heads/master
Now if I push this drbd-8.2.7-merge-branch to the central repo, the
next guy won't
know for sure what this was tracking. I also don't want to have to
'add remote ...'
every time I clone a new copy. Thanks.
Peter
^ permalink raw reply
* git svn mkdirs ignores compressed unhandled.log files
From: Robert Zeh @ 2009-12-17 17:10 UTC (permalink / raw)
To: git; +Cc: Eric Wong
It looks like there is a conflict between git svn gc and git svn mkdirs. The git svn mkdirs command only looks at unhandled.log files. Shouldn't it also look at any compressed unhandled.log files too?
Robert
^ permalink raw reply
* Re: diff attribute ignored by show and log -p
From: Jay Soffian @ 2009-12-17 16:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091217221740.6117@nanako3.lavabit.com>
On Thu, Dec 17, 2009 at 8:17 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Jay Soffian <jaysoffian@gmail.com>
>
>>> But is apparently ignored by "git log -p" and "git show" which just
>>> use internal diff. Is this behavior intentional?
>>
>> Ah, --ext-diff, and the reasoning behind requiring it for log/show is
>> explained in 72909be.
>
> The need to give --ext-diff is mentioned in 72909be (Add diff-option
> --ext-diff, 2007-06-30) but its log message doesn't 'explain' why external
> diff isn't used by default and you need to pass that extra option.
"To prevent funky games with external diff engines, git-log and
friends prevent external diff engines from being called."
Seemed reason enough to me.
> Probably --ext-diff should be the default?
Or available via a config option anyway.
j.
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-17 16:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912161841210.23173@xanadu.home>
On Thu, 2009-12-17 at 00:38 -0500, Nicolas Pitre wrote:
> Moving the reflog data aside (i.e. mv .git/logs .git/logs.bak) it seems
> that d936ff8 is not referenced anymore.
>
> I found the other one as follows:
>
> First I tried
>
> $ git rev-list --all --objects
>
> This resulted in:
>
> [...]
> 4f7911b0b0dbd187131a109cf00161a0c6a9d727 arch/x86
> ea868257c1eabc31e0ea7941efa42b543978b3fa arch/x86/kvm
> a0c11ead723956c667172a9f3fb6787684fe7ff5 arch/x86/kvm/paging_tmpl.h
> b556b6aad8b1aacfecb1dd4a56dbd389674687b5 arch/x86/kvm/x86.c
> 68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
> error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
> fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
>
> Because of the way objects are enumerated, we can be pretty sure that
> the bad tree object is referenced by the tree object 68a9733a
> corresponding to drivers/. Let's verify that:
>
> $ git ls-tree 68a9733a
> 100644 blob 00cf9553f74065291612b0971337f79995933a06 Kconfig
> 100644 blob c1bf41737936ab00be4a87563a0bb0638074785d Makefile
> 040000 tree d4e847de9bf2450842936582ea7cc6778413825b accessibility
> 040000 tree 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f acpi
This alone almost certainly tells me how I broke it.
For quite some time (a period of months) linux-next was broken and I had
to carry a patch to ACPI to make it boot. I dropped that patch at the
head of my stgit trees in all of my repositories. So I wouldn't be at
all surprised to learn that eventually kernel-2 found that object in
kernel-1. Sometime when I dropped that patch from kernel-1 (because it
finally got fixed upstream) I can see how it broke.
But now that patch shouldn't be needed by any tree since I have long
since dropped it from the stgit stack. So if we cleaned up all of the
useless objects in this tree I bet this object wouldn't be needed. Not
exactly a situation that I'd expect git to be able to dig out of itself
thought.
I'm creating clean repos and going to do no work in my -alt :)
Thanks everyone!
-Eric
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Jakub Narebski @ 2009-12-17 15:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1261040753-4859-1-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
> In views that support --no-merges, introduce a link that toggles the
> option.
I like this idea of introducing interface for so far hidden feature
(well, except hidden in one of feed <link ...> in page header).
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>
> ---
> gitweb/gitweb.css | 11 +++++++++++
> gitweb/gitweb.perl | 14 ++++++++++++++
> 2 files changed, 25 insertions(+), 0 deletions(-)
>
> This is something I've been wanting for a while. There are a number of
> things that don't 'click' with this proof of concept, and I'm coming to
> the list to hear the opinion of users and developers on how to improve
> the thing.
>
> The patch is live at http://git.oblomov.eu/, an example affected page is
> http://git.oblomov.eu/git/shortlog
You should tell here that one must put mouse over main header (the one
with 'projects / project / action' breadcrumbs) for the new link to be
visible... because I was wondering where is this new link.
>
> Things that are sure to change:
>
> * the aesthetics and location of the toggle link (it shows on mousehover
> in the title).
It is not only the question where to put link, but also where to put
the *code* (where the code should belong to).
At first I thought: WTF? Why the feature that deals with log-like views
is put in very generic and common for all actions/views git_header_html
subroutine? Especially after change that made all loglike views use
common infrastructure of git_log_generic.
But then I realized that it is specific example of *generic* feature
that deals with extra_options... which admittedly is currently limited
to '--no-merges' only. So if it is put in git_header_html, then all
views with HTML output (which does not include 'atom' and 'rss' actions,
but which actions IIRC have their own handling of '--no-merges')
which have support for extra_options would have ability to turn them
on and off.
What you need to add (if this link is to be in git_header_html) is
to create links only when $status == 200, because otherwise the link
would be present also for error pages, which I think is wrong.
> Other options I've considered are:
> + next to pagination (first | prev | next), either before or after
> the existing entries
This would fit with the fact that sometimes present "patches" link is on
the line with pagination links, after pagination links.
But this secondary navigation bar is about other views, and extra_options
is about modifying current view, and functions more like toggles. OTOH
we have such toggle for 'blame' <-> 'blame_incremental' switch in
secondary navigation bar.
Also this would mean that each view type would have to handle extra_options
itself, as secondary navigation bar is very much action-specific. Not
that it matters now, with only single '--no-merges' option supported.
> + on mouseover for the table section that refers to the (short)log;
> this would make it possible to put it summary view too, for example
This would mean having link inside link, as those headers in summary view
functions as link to 'shortlog' view (quite useful I think), and to the
project summary in the 'shortlog' view itself (I'm not sure how useful
that is). We already have problems with ref markers being links inside
links and having broken layout in some strict XHTML conformance browsers.
In short: I am not sure what would be the best solution. Nevertheless
I think that link should be more visible, and perhaps more toggle-like.
> * if you toggle merge view when not on the first page, the reference
> (first) commit in the view is likely to change drastically, which
> causes confusion. I have not found a satisfactory solution for this,
> since the obvious way to 'lock' the view (start paginating from the
> current top commit) prevents prev/next navigation
Alternate solution would be to clean page (start from 0th page) when
changing to '--no-merges'.
You would probably need something like 'skip' option, with number of
commits, not number of pages to skip, and/or 'skip_to' which takes
commit-id. But i have not thought about this much...
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 50067f2..0da6ef0 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -572,3 +572,14 @@ span.match {
> div.binary {
> font-style: italic;
> }
> +
> +span.merge_toggle a {
> + font-size: 66%;
> + color: white !important;
> + font-weight: normal;
> + vertical-align: top;
> + text-decoration:none;
> + visibility: hidden;
> +}
I think it should be more visible.
Otherwise only people "in the know" would be able to use this.
> +
> +*:hover > span.merge_toggle a { visibility:visible }
I'd rather not have this rule to have different style, i.e. not all
in single line. Unless it is for RFC only...
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7e477af..a63f419 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3118,11 +3118,15 @@ sub git_header_html {
> my $status = shift || "200 OK";
> my $expires = shift;
>
> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
> + my $has_merges = !grep(/^--no-merges$/, @extra_options);
> +
Wouldn't it be better to use straight
+ my $no_merges = grep(/^--no-merges$/, @extra_options);
Because $has_merges is true also for example for 'tree' view... which
absolutely doesn't make any sense whatsoever.
In more generic solution (which could be perhaps put in a separate commit)
it could be:
+ my %extra_options = map { $_ => 0 } keys %$allowed_options;
+ $extra_options{$_} = 1 foreach @extra_options;
which means that %extra_options is hash which keys are allowed options,
and which has true value for allowed option which is actually used.
Or something like that, if above is to cryptic.
> my $title = "$site_name";
> if (defined $project) {
> $title .= " - " . to_utf8($project);
> if (defined $action) {
> $title .= "/$action";
> + $title .= " (no merges)" unless $has_merges;
Wouldn't it be better to use
+ $title .= " (no merges)" if $no_merges;
More straightforward, and without misleading $has_merges.
> if (defined $file_name) {
> $title .= " - " . esc_path($file_name);
> if ($action eq "tree" && $file_name !~ m|/$|) {
> @@ -3235,6 +3239,16 @@ EOF
> print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
> if (defined $action) {
> print " / $action";
> + if ($can_have_merges) {
> + print " <span class='merge_toggle'>";
> + if ($has_merges) {
> + printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
It would be more symmetric to use:
+ my @href_extra = ('--no-merges', @extra_options);
+ printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> + } else {
> + my @href_extra = grep(!/^--no-merges$/, @extra_options);
> + printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> + }
and then this conditional could be simplified a bit.
> + print "</span>";
> + }
> }
> print "\n";
> }
> --
> 1.6.3.rc1.192.gdbfcb
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Pat Notz @ 2009-12-17 15:04 UTC (permalink / raw)
To: bd; +Cc: git
In-Reply-To: <20091216101647.GB27373@bc-bd.org>
> So how do I:
>
> git please-tell-me-the-branch-I-started-this-branch-from new
>
You may also be interested in the git show-branch command. The output
may be unintuitive at first but once you grok it it's pretty useful...
especially if you have several branches.
Aside from the man page, here's a blog post the describes the output:
https://wincent.com/wiki/Understanding_the_output_of_%22git_show-branch%22
~ Pat
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Stefan Völkel @ 2009-12-17 14:20 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Elijah Newren, git
In-Reply-To: <20091217002024.GM25474@genesis.frugalware.org>
Hi,
> git log $(git reflog show new|sed -n 's/ .*//;$ p')..new
I had trouble getting the above to work as a git alias (someething wrt
escaping I guess), however this:
gl = log --graph --pretty=oneline --abbrev-commit
bl = !sh -c 'git gl $0 --not $(git for-each-ref --format=%\\(refname\\)
refs/heads/* | grep -v refs/heads/$0)'
does exactly what I want:
# git reflog show new
76cacd3 new@{0}: commit: B
9638379 new@{1}: commit: A
7944f55 new@{2}: branch: Created from HEAD
# git gl
* 76cacd3 B
* 9638379 A
* 7944f55 Y
* b8e4a96 X
# git bl new
* 76cacd3 B
* 9638379 A
Thanks for the help,
Stefan
^ permalink raw reply
* Re: diff attribute ignored by show and log -p
From: Nanako Shiraishi @ 2009-12-17 13:17 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490912162123r49f9bd90n8e032c144d0cdbac@mail.gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>
>> But is apparently ignored by "git log -p" and "git show" which just
>> use internal diff. Is this behavior intentional?
>
> Ah, --ext-diff, and the reasoning behind requiring it for log/show is
> explained in 72909be.
The need to give --ext-diff is mentioned in 72909be (Add diff-option
--ext-diff, 2007-06-30) but its log message doesn't 'explain' why external
diff isn't used by default and you need to pass that extra option.
Probably --ext-diff should be the default?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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