* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <7vljt1u4pc.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 21:50, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>> I would find the H flag practical for my own usage of submodules. I
>> almost never modify the content of the currently checked out submodule
>> but I often check out a different HEAD than what is registered in the
>> gitlink in the superproject (typically due to testing the superproject
>> against different versions of the submodule). And for such a use case,
>> being able to create a tarball of my currently checked out state seems
>> useful to me.
>
> That would be more like an enhanced version of "git archive" that takes
> the work tree state, similar to how "git grep" operates on the work tree
> today.
>
> I agree that would be useful, but I have a moderately strong suspition
> that your "H" hack that includes the work tree state for checked out
> submodules into a view that is primarily about the "tree" object in the
> superproject, without the same "take from the work tree" semantics for
> paths in the superproject, is more harmful than being helpful to the users
> in the longer term. It might be simple to implement, but I do not think
> its semantics can be explained sanely.
Ok. When someone gets the itch for 'git archive --worktree', it would
be easy enough to resurrect the idea of including the tree of the
currently checked out HEAD in selected submodules.
Do you think the other options makes any sense, i.e. is it any point
in me trying to implement this?
--
larsh
^ permalink raw reply
* [PATCH (GIT-GUI BUG)] git-gui: Fix post-commit status with subject in non-locale encoding.
From: Alexander Gavrilov @ 2009-01-23 21:18 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg
As pointed out in msysgit bug #181, when a non-locale encoding
is used for commits, post-commit status messages display the
subject incorrectly. It happens because the file handle is
not properly configured before the subject is read back.
This patch fixes it by factoring out the code that is
used to setup the output handle into a separate function,
and calling it from the reading code.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
The original bug report:
http://code.google.com/p/msysgit/issues/detail?id=181
lib/commit.tcl | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 9cc8410..17aba91 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -115,6 +115,23 @@ proc create_new_commit {} {
rescan ui_ready
}
+proc setup_commit_encoding {msg_wt {quiet 0}} {
+ global repo_config
+
+ if {[catch {set enc $repo_config(i18n.commitencoding)}]} {
+ set enc utf-8
+ }
+ set use_enc [tcl_encoding $enc]
+ if {$use_enc ne {}} {
+ fconfigure $msg_wt -encoding $use_enc
+ } else {
+ if {!$quiet} {
+ error_popup [mc "warning: Tcl does not support encoding '%s'." $enc]
+ }
+ fconfigure $msg_wt -encoding utf-8
+ }
+}
+
proc commit_tree {} {
global HEAD commit_type file_states ui_comm repo_config
global pch_error
@@ -200,16 +217,7 @@ A good commit message has the following format:
set msg_p [gitdir GITGUI_EDITMSG]
set msg_wt [open $msg_p w]
fconfigure $msg_wt -translation lf
- if {[catch {set enc $repo_config(i18n.commitencoding)}]} {
- set enc utf-8
- }
- set use_enc [tcl_encoding $enc]
- if {$use_enc ne {}} {
- fconfigure $msg_wt -encoding $use_enc
- } else {
- error_popup [mc "warning: Tcl does not support encoding '%s'." $enc]
- fconfigure $msg_wt -encoding utf-8
- }
+ setup_commit_encoding $msg_wt
puts $msg_wt $msg
close $msg_wt
@@ -362,6 +370,7 @@ A rescan will be automatically started now.
append reflogm " ($commit_type)"
}
set msg_fd [open $msg_p r]
+ setup_commit_encoding $msg_fd 1
gets $msg_fd subject
close $msg_fd
append reflogm {: } $subject
--
1.6.1.63.g950db
^ permalink raw reply related
* Re: [PATCH] gittutorial: remove misleading note
From: Miklos Vajna @ 2009-01-23 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk58lvoe5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Fri, Jan 23, 2009 at 11:00:18AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> So we have a usability regression here. Perhaps we need to fix that
> instead?
I thought that's on purpose.
By doing a 'git fetch <url>' I don't say "what" to fetch, just "from
where".
Would it be better to fetch HEAD in that case?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Robin Rosenberg @ 2009-01-23 21:33 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: Shawn O. Pearce, git
In-Reply-To: <p06240812c59ed365d694@[192.168.1.106]>
fredag 23 januari 2009 02:56:16 skrev Stephen Bannasch:
> At 6:27 PM -0500 1/13/09, Stephen Bannasch wrote:
...
> >Done: http://code.google.com/p/egit/issues/detail?id=52
> >
> >Fxing this will make using Eclipse and Git together SO much nicer!
>
> Robin and Shawn,
>
> Can you suggest where in the egit code I should look to see if I can fix this?
There may be more than one place.
Take a look at GitResourceDecorator.
We map from resources using code like this:
RepositoryMapping.getMapping(rsrc) // <-- prime suspect
Repository.getRepoRelativePath(rsrc)
Repository.getWorkDir
Repository.isResourceChanged
I'm not entirely sure this is the correct way, but it probably has no
bearing on your problem.
GitResourceDecorator decorator = getActiveDecorator();
It would be nice with a unit test for this. (Not necessarily the decorator,
but the methods used for it).
-- robin
^ permalink raw reply
* Re: [JGIT PATCH 02/10] Expose the raw path for the current entry of a TreeWalk
From: Robin Rosenberg @ 2009-01-23 21:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1232666890-23488-3-git-send-email-spearce@spearce.org>
fredag 23 januari 2009 00:28:02 skrev Shawn O. Pearce:
> Copying the path byte array (keeping it encoded in UTF-8) is quicker
> than converting to String and then back again to UTF-8 when creating
> a DirCacheEntry for the current position in a TreeWalk.
[...]
> + * Get the current entry's complete path as a UTF-8 byte array.
/Hopefully/ UTF-8. It is often a legacy encoding, like ISO-8859-X, CP12xx
etc. I'll come up with something less specific that just UTF-8.
-- robin
^ permalink raw reply
* [RFC PATCH (GIT-GUI/CORE BUG)] git-gui: Avoid an infinite rescan loop in handle_empty_diff.
From: Alexander Gavrilov @ 2009-01-23 21:52 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano, Andy Davey, kbro
If the index update machinery and git diff happen to disagree
on whether a particular file is modified, it may cause git-gui
to enter an infinite index rescan loop, where an empty diff
starts a rescan, which finds the same set of files modified,
and tries to display the diff for the first one, which happens
to be the empty one. A current example of a possible disagreement
point is the autocrlf filter.
This patch breaks the loop by using a global variable to track
the auto-rescans. The variable is reset whenever a non-empty
diff is displayed. As a way to work around the malfunctioning
index rescan command, it resurrects the pre-0.6.0 code that
directly updates only the affected file.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Note that if the file is actually modified, and the bug is
either in git-diff or the way git-gui calls it, this patch
will stage the file without displaying it in the UI. Thus, it
may be better to simply do nothing if the loop prevention
logic triggers.
On Jan 22, 11:31 pm, kbro <kevin.broa...@googlemail.com> wrote:
> However, for me it was worse as the "No differences" message popped up
> as soon as I opened git-gui, and the dialog said it would run a rescan
> to find all files in a similar state. The rescan caused the same
> error to be detected again, so I could never get the dialog box to go
> away.
On Friday 23 January 2009 02:56:23 Andy Davey wrote:
> I had the exact same problem you described running git-1.6.1-
> preview20081227 on Windows XP as well. (the endless loop of dialog box
> is very frustrating).
P.S. Steps to reproduce the autocrlf handling mismatch on Linux:
$ git init
$ echo > foo
$ git add foo && git commit -m init
$ unix2dos -o foo
$ git config core.autocrlf true
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git diff foo
diff --git a/foo b/foo
It happens because git-status assumes that a change in
file size always means that the file contents have changed.
Content filters like autocrlf may invalidate this assumption.
lib/diff.tcl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bbbf15c..e5abb49 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -51,6 +51,7 @@ proc force_diff_encoding {enc} {
proc handle_empty_diff {} {
global current_diff_path file_states file_lists
+ global last_empty_diff
set path $current_diff_path
set s $file_states($path)
@@ -66,7 +67,17 @@ A rescan will be automatically started to find other files which may have the sa
clear_diff
display_file $path __
- rescan ui_ready 0
+
+ if {![info exists last_empty_diff]} {
+ set last_empty_diff $path
+ rescan ui_ready 0
+ } else {
+ # We already tried rescanning recently, and it failed,
+ # so resort to updating this particular file.
+ if {[catch {git update-index -- $path} err]} {
+ error_popup [mc "Failed to refresh index:\n\n%s" $err]
+ }
+ }
}
proc show_diff {path w {lno {}} {scroll_pos {}} {callback {}}} {
@@ -310,6 +321,7 @@ proc read_diff {fd cont_info} {
global ui_diff diff_active
global is_3way_diff is_conflict_diff current_diff_header
global current_diff_queue
+ global last_empty_diff
$ui_diff conf -state normal
while {[gets $fd line] >= 0} {
@@ -415,6 +427,8 @@ proc read_diff {fd cont_info} {
if {[$ui_diff index end] eq {2.0}} {
handle_empty_diff
+ } else {
+ catch { unset last_empty_diff }
}
set callback [lindex $cont_info 1]
if {$callback ne {}} {
--
1.6.1.63.g950db
^ permalink raw reply related
* Re: [PATCH] Allow cloning an empty repository
From: Mike Hommey @ 2009-01-23 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901230333060.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 03:42:24AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
>
> > On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> > > I think the basic idea is Ok, but is it a reliable check at this point to
> > > see if (refs == NULL) to tell if the target repository is an empty one?
> >
> > This is the question I asked Dscho, and he said/guessed that it was.
> >
> > > I am mostly worried about a failure case (connected but couldn't get
> > > the refs, or perhaps connection failed to start). If you get a NULL
> > > in such a case you may end up saying "oh you cloned a void" when you
> > > should say "nah, such a remote repository does not exist".
> >
> > Yes, this was my concern as well.
>
> From what I can see in get_remote_heads(), the native protocols would
> die(), as would rsync().
>
> HTTP transport, however, would not die() on connection errors, from my
> cursory look.
>
> That might be skewed, though, as I am on top of Mike's patches (in the
> hopefully not so futile hope that Mike -- after letting me wait for over
> one year -- finishes his work.
As I said when posting my patch batch, I don't have much time nor
motivation to work on this series. But let's make a deal: if someone
writes a good enough http test suite, I'll polish the http code.
Mike
^ permalink raw reply
* Re: [PATCHv2] git mergetool: Don't repeat merge tool candidates
From: Junio C Hamano @ 2009-01-23 22:10 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git, tytso
In-Reply-To: <1232702093-24313-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> git mergetool listed some candidates for mergetools twice, depending on
> the environment.
>
> Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
> ---
> The first patch had the fatal flaw that it listed nothing when DISPLAY
> and EDITOR/VISUAL were unset, we fixed that.
> The order in which merge-candidates appear is still exactly the same,
> only duplicates have been stripped. The check for KDE_FULL_SESSION was
> removed since kdiff3 was added as long as DISPLAY was set and we weren't
> running gnome.
The old code produced this:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ - + kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + - meld kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + + kdiff3 meld kdiff3 tkdiff xxdiff meld gvimdiff (editor)
where (editor) lists emerge or vimdiff if the preferred editor was emacs
or vim, and then opendiff, and then emerge and vimdiff as fallback
duplicates.
Looking at what the new code does for the (editor) fallback part first:
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
fi
if test -z "$merge_tool_candidates" ; then
merge_tool_candidates="opendiff emerge vimdiff"
fi
I think it is better to rewrite this part for clarity:
if EDITOR is emacs?
then
append emerge opendiff vimdiff in this order
elif EDITOR is vim?
then
append vimdiff opendiff emerge in this order
else
append opendiff emerge vimdiff in this order
fi
because emacs and vim cannot be set to EDITOR at the same time
(note that I think this also fixes a bug; see below).
> if test -n "$DISPLAY"; then
> if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
> + merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
> + else
> + merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> fi
> fi
This one produces:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor')
+ - + kdiff3 tkdiff xxdiff meld gvimdiff (editor')
+ + - meld kdiff3 tkdiff xxdiff gvimdiff (editor')
+ + + meld kdiff3 tkdiff xxdiff gvimdiff (editor')
where "(editor')" is empty if your EDITOR is not emacs nor vim.
The original list with the duplicates removed is:
DISPLAY set
| GNOME_DESKTOP_SESSION_ID set
| | KDE_FULL_SESSION true
| | |
- - - (editor)
- - + (editor)
- + - (editor)
- + + (editor)
+ - - kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ - + kdiff3 tkdiff xxdiff meld gvimdiff (editor)
+ + - meld kdiff3 tkdiff xxdiff gvimdiff (editor)
+ + + kdiff3 meld tkdiff xxdiff gvimdiff (editor)
Aside from the "(editor') is empty when DISPLAY is set" difference, the
result is also different iff GNOME_DESKTOP_SESSION_ID and KDE_FULL_SESSION
are both set. I am guessing that that does not happen in a sane
environment, though.
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Jeff King @ 2009-01-23 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git list, Christian MICHON
In-Reply-To: <7vtz7qxsxc.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 01:39:27AM -0800, Junio C Hamano wrote:
> > --->8---
> > Subject: [PATCH] git-am: Add --ignore-date option
>
> Good.
>
> Leaving "Subject: " in saves me typing, because I do not have to insert it
> manually when editing the submitted patch in my MUA to chop off everything
> before the scissors.
Interesting to know. I have intentionally _not_ been including them,
because I assumed you marked up _after_ git-am (i.e., via "git commit
--amend) in which case you would have to delete it manually. I suppose
it makes more sense to do so before git-am, though, since then it will
respect From: fields and the like (which it would otherwise ignore,
since they are blocked by all of the cover letter cruft that you will
end up deleting).
So good to know, and I will start generating my patches differently.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Jeff King @ 2009-01-23 22:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230419080.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin wrote:
> Probably. Note, however, that scripts might rely on a fail if there were
> problems.
>
> But then, scripts have no business cloning repositories (fetching, yes.
> But cloning?)
Really? I have scripts that call clone (usually followed by building the
result). Are you proposing that all scripts should "git init && git
remote add && git fetch"?
So I am strongly in favor of telling the difference between failure and
emptiness.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090123223205.GA11491@coredump.intra.peff.net>
On Fri, Jan 23, 2009 at 23:32, Jeff King <peff@peff.net> wrote:
> Really? I have scripts that call clone (usually followed by building the
> result). Are you proposing that all scripts should "git init && git
> remote add && git fetch"?
>
> So I am strongly in favor of telling the difference between failure and
> emptiness.
A switch then, '--allow-empty'?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Jeff King @ 2009-01-23 22:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <bd6139dc0901231434n6d6af5a6ma8bb12a634d5b3ba@mail.gmail.com>
On Fri, Jan 23, 2009 at 11:34:04PM +0100, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 23:32, Jeff King <peff@peff.net> wrote:
> > Really? I have scripts that call clone (usually followed by building the
> > result). Are you proposing that all scripts should "git init && git
> > remote add && git fetch"?
> >
> > So I am strongly in favor of telling the difference between failure and
> > emptiness.
>
> A switch then, '--allow-empty'?
No, I don't mind success on cloning an empty repository. But I thought
the issue at hand was that for some instances, we would report that we
successfully created an empty repository, when in fact what happened was
that we failed to clone a non-empty repository. And that that was
fixable, but it was a problem with our code interfaces (which should be
fixable) and not some fundamental limitation.
Or am I misunderstanding the situation?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 22:39 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090123223740.GA11527@coredump.intra.peff.net>
On Fri, Jan 23, 2009 at 23:37, Jeff King <peff@peff.net> wrote:
> No, I don't mind success on cloning an empty repository. But I thought
> the issue at hand was that for some instances, we would report that we
> successfully created an empty repository, when in fact what happened was
> that we failed to clone a non-empty repository. And that that was
> fixable, but it was a problem with our code interfaces (which should be
> fixable) and not some fundamental limitation.
Ah, mhh, if that is the case then I'm afraid that's beyond me (at
least for now), someone else would have to do said refactoring first
:(.
> Or am I misunderstanding the situation?
I think you summarized it pretty well, if that is indeed what Junio meant.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-23 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i4m6cz0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jake Goulding <goulding@vivisimo.com> writes:
>
>> Moving has_commit from branch to a common location in preparation for
>> using it in tag.
>
> has_commit() may have been a good enough name when it was a static in
> builtin-branch.c but with much wider visibility, it is not specific
> enough.
>
> Perhaps you would want to rename it to something more descriptive.
Sure - any suggestions?
The best I could come up with was "commit_has_any_in_commit_list"
> Also it seems that your patch is garbled and won't apply. A blank
> context line lost the leading (and only) SP, and long lines are wrapped.
Yes - adventures in sending patches. Hopefully I'll have it fixed by the
next round of patches. :-)
>
>> Signed-off-by: Jake Goulding <goulding@vivisimo.com>
>> ---
>> builtin-branch.c | 15 ---------------
>> commit.c | 15 +++++++++++++++
>> commit.h | 1 +
>> 3 files changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/builtin-branch.c b/builtin-branch.c
>> index 82d6fb2..bb42911 100644
>> --- a/builtin-branch.c
>> +++ b/builtin-branch.c
>> @@ -193,21 +193,6 @@ struct ref_list {
>> int kinds;
>> };
>>
>> -static int has_commit(struct commit *commit, struct commit_list
>> *with_commit)
>> -{
>> - if (!with_commit)
>> - return 1;
>> - while (with_commit) {
>> - struct commit *other;
>> -
>> - other = with_commit->item;
>> - with_commit = with_commit->next;
>> - if (in_merge_bases(other, &commit, 1))
>> - return 1;
>> - }
>> - return 0;
>> -}
>> -
>> static int append_ref(const char *refname, const unsigned char *sha1,
>> int flags, void *cb_data)
>> {
>> struct ref_list *ref_list = (struct ref_list*)(cb_data);
>> diff --git a/commit.c b/commit.c
>> index c99db16..5ccb338 100644
>> --- a/commit.c
>> +++ b/commit.c
>> @@ -705,6 +705,21 @@ struct commit_list *get_merge_bases(struct commit
>> *one, struct commit *two,
>> return get_merge_bases_many(one, 1, &two, cleanup);
>> }
>>
>> +int has_commit(struct commit *commit, struct commit_list *with_commit)
>> +{
>> + if (!with_commit)
>> + return 1;
>> + while (with_commit) {
>> + struct commit *other;
>> +
>> + other = with_commit->item;
>> + with_commit = with_commit->next;
>> + if (in_merge_bases(other, &commit, 1))
>> + return 1;
>> + }
>> + return 0;
>> +}
>> +
>> int in_merge_bases(struct commit *commit, struct commit **reference,
>> int num)
>> {
>> struct commit_list *bases, *b;
>> diff --git a/commit.h b/commit.h
>> index 3a7b06a..1b8444f 100644
>> --- a/commit.h
>> +++ b/commit.h
>> @@ -133,6 +133,7 @@ extern int is_repository_shallow(void);
>> extern struct commit_list *get_shallow_commits(struct object_array *heads,
>> int depth, int shallow_flag, int not_shallow_flag);
>>
>> +int has_commit(struct commit *, struct commit_list *);
>> int in_merge_bases(struct commit *, struct commit **, int);
>>
>> extern int interactive_add(int argc, const char **argv, const char
>> *prefix);
>> --
>> 1.6.0.4
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Miklos Vajna @ 2009-01-23 23:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230333060.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Fri, Jan 23, 2009 at 03:42:24AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > I am mostly worried about a failure case (connected but couldn't get
> > > the refs, or perhaps connection failed to start). If you get a NULL
> > > in such a case you may end up saying "oh you cloned a void" when you
> > > should say "nah, such a remote repository does not exist".
> >
> > Yes, this was my concern as well.
>
> From what I can see in get_remote_heads(), the native protocols would
> die(), as would rsync().
>
> HTTP transport, however, would not die() on connection errors, from my
> cursory look.
I'm not familiar with the HTTP code, either, but here is the call stack
I see:
- builtin-clone calls transport_get_remote_refs()
- that will call transport->get_refs_list()
- that will call get_refs_via_curl()
- that die()s on error, does not use return error()
Have I missed something?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCHv3] git mergetool: Don't repeat merge tool candidates
From: Johannes Gilger @ 2009-01-23 23:12 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Gilger
In-Reply-To: <7vpridr7vb.fsf@gitster.siamese.dyndns.org>
git mergetool listed some candidates for mergetools twice, depending on
the environment.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
This improves on v2 of this patch as it appends non-gui merge-tools even
if $DISPLAY is set. It still makes the assumption that KDE_FULL_SESSION
and GNOME_DESKTOP_SESSION_ID are never set at the same time. If this
were to happen the tool would simply prefer meld over kdiff3.
git-mergetool.sh | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..09f3a10 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -390,21 +390,19 @@ fi
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld $merge_tool_candidates"
- fi
- if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
+ else
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
- fi
- if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates vimdiff"
+ merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
+ elif echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
+ else
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
fi
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
init_merge_tool_path $i
--
1.6.1.40.g8ea6a
^ permalink raw reply related
* [PATCH v2] Change octal literals to be XEmacs friendly
From: Vassili Karpov @ 2009-01-23 23:20 UTC (permalink / raw)
To: git, Alexandre Julliard
The type-of ?\octal in XEmacs is character while in FSF Emacs it is
integer. Case expression using this syntax will not work correctly on
XEmacs. #ooctal syntax on the other hand produces integers everywhere.
Signed-off-by: Vassili Karpov <av1474@comtv.ru>
---
contrib/emacs/git.el | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 09e8bae..715580a 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -562,29 +562,29 @@ the process output as a string, or nil if the git
command failed."
(let* ((old-type (lsh (or old-perm 0) -9))
(new-type (lsh (or new-perm 0) -9))
(str (case new-type
- (?\100 ;; file
+ (#o100 ;; file
(case old-type
- (?\100 nil)
- (?\120 " (type change symlink -> file)")
- (?\160 " (type change subproject -> file)")))
- (?\120 ;; symlink
+ (#o100 nil)
+ (#o120 " (type change symlink -> file)")
+ (#o160 " (type change subproject -> file)")))
+ (#o120 ;; symlink
(case old-type
- (?\100 " (type change file -> symlink)")
- (?\160 " (type change subproject -> symlink)")
+ (#o100 " (type change file -> symlink)")
+ (#o160 " (type change subproject -> symlink)")
(t " (symlink)")))
- (?\160 ;; subproject
+ (#o160 ;; subproject
(case old-type
- (?\100 " (type change file -> subproject)")
- (?\120 " (type change symlink -> subproject)")
+ (#o100 " (type change file -> subproject)")
+ (#o120 " (type change symlink -> subproject)")
(t " (subproject)")))
- (?\110 nil) ;; directory (internal, not a real git
state)
- (?\000 ;; deleted or unknown
+ (#o110 nil) ;; directory (internal, not a real git
state)
+ (#o000 ;; deleted or unknown
(case old-type
- (?\120 " (symlink)")
- (?\160 " (subproject)")))
+ (#o120 " (symlink)")
+ (#o160 " (subproject)")))
(t (format " (unknown type %o)" new-type)))))
(cond (str (propertize str 'face 'git-status-face))
- ((eq new-type ?\110) "/")
+ ((eq new-type #o110) "/")
(t ""))))
(defun git-rename-as-string (info)
--
1.6.0.2.GIT
--
mailto:av1474@comtv.ru
^ permalink raw reply related
* http fixes, was Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-24 0:26 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20090123215559.GA5561@glandium.org>
Hi,
On Fri, 23 Jan 2009, Mike Hommey wrote:
> As I said when posting my patch batch, I don't have much time nor
> motivation to work on this series. But let's make a deal: if someone
> writes a good enough http test suite, I'll polish the http code.
I already said in my replied to your patch that I will add the http test
suite if you fix your patches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-24 0:28 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090123223740.GA11527@coredump.intra.peff.net>
Hi,
On Fri, 23 Jan 2009, Jeff King wrote:
> But I thought the issue at hand was that for some instances, we would
> report that we successfully created an empty repository, when in fact
> what happened was that we failed to clone a non-empty repository. And
> that that was fixable, but it was a problem with our code interfaces
> (which should be fixable) and not some fundamental limitation.
It appears that the HTTP code (at least after the first round of Mike's
patches) has issues there, yes, but I think it would not be fair to stop
Sverre's patch because of that: the HTTP code needs fixing anyway, and
this fix is orthogonal to the empty clones.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-24 0:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090123230520.GL21473@genesis.frugalware.org>
Hi,
On Sat, 24 Jan 2009, Miklos Vajna wrote:
> On Fri, Jan 23, 2009 at 03:42:24AM +0100, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > > > I am mostly worried about a failure case (connected but couldn't
> > > > get the refs, or perhaps connection failed to start). If you get
> > > > a NULL in such a case you may end up saying "oh you cloned a void"
> > > > when you should say "nah, such a remote repository does not
> > > > exist".
> > >
> > > Yes, this was my concern as well.
> >
> > From what I can see in get_remote_heads(), the native protocols would
> > die(), as would rsync().
> >
> > HTTP transport, however, would not die() on connection errors, from my
> > cursory look.
>
> I'm not familiar with the HTTP code, either, but here is the call stack
> I see:
>
> - builtin-clone calls transport_get_remote_refs()
> - that will call transport->get_refs_list()
> - that will call get_refs_via_curl()
> - that die()s on error, does not use return error()
>
> Have I missed something?
Not really.
Only after writing my email (and just before sending) did I remember that
I have Mike's HTTP cleanups applied in my Git checkout. So I was
analyzing the wrong code.
Thanks for analyzing the right code.
Ciao,
Dscho
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Johannes Schindelin @ 2009-01-24 0:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git list, Christian MICHON
In-Reply-To: <20090123222906.GC11328@coredump.intra.peff.net>
Hi,
On Fri, 23 Jan 2009, Jeff King wrote:
> On Fri, Jan 23, 2009 at 01:39:27AM -0800, Junio C Hamano wrote:
>
> > > --->8---
> > > Subject: [PATCH] git-am: Add --ignore-date option
> >
> > Good.
> >
> > Leaving "Subject: " in saves me typing, because I do not have to insert it
> > manually when editing the submitted patch in my MUA to chop off everything
> > before the scissors.
>
> Interesting to know. I have intentionally _not_ been including them,
> because I assumed you marked up _after_ git-am (i.e., via "git commit
> --amend) in which case you would have to delete it manually. I suppose
> it makes more sense to do so before git-am, though, since then it will
> respect From: fields and the like (which it would otherwise ignore,
> since they are blocked by all of the cover letter cruft that you will
> end up deleting).
>
> So good to know, and I will start generating my patches differently.
Note that your patches will not be found using Pasky's "mail" link in
gitweb, if you do not put the commit subject into the _real_ mail subject.
Dunno if I like that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-24 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901240131570.3586@pacific.mpi-cbg.de>
On Sat, Jan 24, 2009 at 01:33, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sat, 24 Jan 2009, Miklos Vajna wrote:
>> I'm not familiar with the HTTP code, either, but here is the call stack
>> I see:
>>
>> - builtin-clone calls transport_get_remote_refs()
>> - that will call transport->get_refs_list()
>> - that will call get_refs_via_curl()
>> - that die()s on error, does not use return error()
Which means all protocols actually die?
> Only after writing my email (and just before sending) did I remember that
> I have Mike's HTTP cleanups applied in my Git checkout. So I was
> analyzing the wrong code.
Hmmm, can't blame you considering it was around 4am ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Jeff King @ 2009-01-24 0:52 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Nanako Shiraishi, git list, Christian MICHON
In-Reply-To: <alpine.DEB.1.00.0901240133510.3586@pacific.mpi-cbg.de>
On Sat, Jan 24, 2009 at 01:34:41AM +0100, Johannes Schindelin wrote:
> > So good to know, and I will start generating my patches differently.
>
> Note that your patches will not be found using Pasky's "mail" link in
> gitweb, if you do not put the commit subject into the _real_ mail subject.
>
> Dunno if I like that.
I think that is not a new problem. Quite a few patches are "how about
this" patches in the middle of a thread, and leave the old subject.
IMHO, that is a failing of the tool in not tracking common practice, not
the other way around.
-Peff
^ permalink raw reply
* Re: [PATCH] git-am: implement --reject option passed to git-apply
From: Junio C Hamano @ 2009-01-24 0:59 UTC (permalink / raw)
To: martin f. krafft; +Cc: git, penny leach
In-Reply-To: <1232670681-25781-1-git-send-email-madduck@madduck.net>
"martin f. krafft" <madduck@madduck.net> writes:
> The patch does not touch t/t4252-am-options.sh (yet) because I do not really
> understand how the testing system works.
I'll squash this in, then.
Thanks.
t/t4252-am-options.sh | 11 ++++++++++-
t/t4252/am-test-6-1 | 21 +++++++++++++++++++++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git c/t/t4252-am-options.sh i/t/t4252-am-options.sh
index 5fdd188..f603c1b 100755
--- c/t/t4252-am-options.sh
+++ i/t/t4252-am-options.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='git am not losing options'
+test_description='git am with options and not losing them'
. ./test-lib.sh
tm="$TEST_DIRECTORY/t4252"
@@ -66,4 +66,13 @@ test_expect_success 'apply to a funny path' '
test -f "$with_sq/file-5"
'
+test_expect_success 'am --reject' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am --reject "$tm"/am-test-6-1 &&
+ grep "@@ -1,3 +1,3 @@" file-2.rej &&
+ test_must_fail git diff-files --exit-code --quiet file-2 &&
+ grep "[-]-reject" .git/rebase-apply/apply-opt
+'
+
test_done
diff --git c/t/t4252/am-test-6-1 i/t/t4252/am-test-6-1
new file mode 100644
index 0000000..a8859e9
--- /dev/null
+++ i/t/t4252/am-test-6-1
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Huh
+
+Should fail and leave rejects
+
+diff --git i/file-2 w/file-2
+index 06e567b..b6f3a16 100644
+--- i/file-2
++++ w/file-2
+@@ -1,3 +1,3 @@
+-0
++One
+ 2
+ 3
+@@ -4,4 +4,4 @@
+ 4
+ 5
+-6
++Six
+ 7
^ permalink raw reply related
* [PATCH 1/2] am: Add --committer-date-is-author-date option
From: Nanako Shiraishi @ 2009-01-24 1:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 22 Jan 2009 16:14:58 -0800
This new option tells 'git-am' to use the timestamp recorded
in the Email message as both author and committer date.
Signed-off-by: しらいしななこ <nanako3@lavabit.com>
---
git-am.sh | 13 ++++++++++++-
t/t4150-am.sh | 20 ++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index e20dd88..e96071d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -23,6 +23,7 @@ resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
+committer-date-is-author-date lie about committer date
rebasing (internal use for git-rebase)"
. git-sh-setup
@@ -133,6 +134,7 @@ dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
resolvemsg= resume=
git_apply_opt=
+committer_date_is_author_date=
while test $# != 0
do
@@ -168,6 +170,8 @@ do
git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
+ --committer-date-is-author-date)
+ committer_date_is_author_date=t ;;
--)
shift; break ;;
*)
@@ -521,7 +525,14 @@ do
tree=$(git write-tree) &&
parent=$(git rev-parse --verify HEAD) &&
- commit=$(git commit-tree $tree -p $parent <"$dotest/final-commit") &&
+ commit=$(
+ if test -n "$committer_date_is_author_date"
+ then
+ GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
+ export GIT_COMMITTER_DATE
+ fi &&
+ git commit-tree $tree -p $parent <"$dotest/final-commit"
+ ) &&
git update-ref -m "$GIT_REFLOG_ACTION: $FIRSTLINE" HEAD $commit $parent ||
stop_here $this
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 796f795..8d3fb00 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -257,4 +257,24 @@ test_expect_success 'am works from file (absolute path given) in subdirectory' '
test -z "$(git diff second)"
'
+test_expect_success 'am --committer-date-is-author-date' '
+ git checkout first &&
+ test_tick &&
+ git am --committer-date-is-author-date patch1 &&
+ git cat-file commit HEAD | sed -e "/^$/q" >head1 &&
+ at=$(sed -ne "/^author /s/.*> //p" head1) &&
+ ct=$(sed -ne "/^committer /s/.*> //p" head1) &&
+ test "$at" = "$ct"
+'
+
+test_expect_success 'am without --committer-date-is-author-date' '
+ git checkout first &&
+ test_tick &&
+ git am patch1 &&
+ git cat-file commit HEAD | sed -e "/^$/q" >head1 &&
+ at=$(sed -ne "/^author /s/.*> //p" head1) &&
+ ct=$(sed -ne "/^committer /s/.*> //p" head1) &&
+ test "$at" != "$ct"
+'
+
test_done
--
1.6.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox