* Re: [PATCH v3 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Jeff King @ 2010-01-05 6:32 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20091224154445.ad4b7a01.rctay89@gmail.com>
On Thu, Dec 24, 2009 at 03:44:45PM +0800, Tay Ray Chuan wrote:
> - ref->status = status;
> - ref->remote_status = msg;
> + switch (ref->status) {
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + case REF_STATUS_UPTODATE:
> + /*
> + * Earlier, the ref was marked not to be pushed, so ignore what
> + * the remote helper said about the ref.
> + */
> + continue;
> + default:
> + ref->status = status;
> + ref->remote_status = msg;
> + }
It seems like this should be checking for REF_STATUS_NONE explicitly
instead of trying to enumerate the reasons we might not have tried to
push. Shouldn't helpers _only_ be pushing REF_STATUS_NONE refs?
I think right now the two cases are equivalent, since non-ff and
uptodate are the only two states set before the helper is invoked. But
we have discussed in the past (and I still have a patch floating around
for) a REF_STATUS_REWIND which would treat strict rewinds differently
(silently ignoring them instead of making an error). Explicitly checking
REF_STATUS_NONE future-proofs against new states being added.
-Peff
^ permalink raw reply
* [PATCH] Documentation: reset: add some missing tables
From: Christian Couder @ 2010-01-05 5:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
and while at it also explain why --merge option is disallowed in some
cases.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 35 +++++++++++++++++++++++++++++------
1 files changed, 29 insertions(+), 6 deletions(-)
I must say that I find it a bit strange (and difficult to explain) that
we have:
working index HEAD target working index HEAD
----------------------------------------------------
B C C C --merge B C C
while in the other cases, when it is allowed, --merge is like --hard.
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index dc73dca..1f35278 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -79,6 +79,13 @@ git reset --option target
to reset the HEAD to another commit (`target`) with the different
reset options depending on the state of the files.
+In these tables, A, B, C and D are some different states of a
+file. For example, the first line of the first table means that if a
+file is in state A in the working tree, in state B in the index, in
+state C in HEAD and in state D in the target, then "git reset --soft
+target" will put the file in state A in the working tree, in state B
+in the index and in state D in HEAD.
+
working index HEAD target working index HEAD
----------------------------------------------------
A B C D --soft A B D
@@ -107,12 +114,28 @@ reset options depending on the state of the files.
--hard C C C
--merge C C C
-In these tables, A, B, C and D are some different states of a
-file. For example, the last line of the last table means that if a
-file is in state B in the working tree and the index, and in a
-different state C in HEAD and in the target, then "git reset
---merge target" will put the file in state C in the working tree,
-in the index and in HEAD.
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+
+"reset --merge" is meant to be used when resetting out of a conflicted
+merge. Any mergy operation guarantees that the work tree file that is
+involved in the merge does not have local change wrt the index before
+it starts, and that it writes the result out to the work tree. So if
+we see some difference between the index and the target and also
+between the index and the work tree, then it means that we are not
+resetting out from a state that a mergy operation left after failing
+with a conflict. That is why we disallow --merge option in this case.
The following tables show what happens when there are unmerged
entries:
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-05 5:57 UTC (permalink / raw)
To: git
In-Reply-To: <7vljgei7rs.fsf@alter.siamese.dyndns.org>
I am tempted to merge the following to 'next' soonish; please complain and
stop me before I do so in a few days if there are issues.
* da/difftool (2009-12-22) 2 commits
* jh/gitweb-cached (2010-01-03) 4 commits
* tc/test-locate-httpd (2010-01-02) 1 commit
* tc/smart-http-restrict (2010-01-02) 4 commits
* jc/branch-d (2009-12-29) 1 commit
http://thread.gmane.org/gmane.comp.version-control.git/135837/focus=135863
* mm/diag-path-in-treeish (2009-12-07) 1 commit
* mh/rebase-fixup (2009-12-07) 2 commits
* ns/rebase-auto-squash (2009-12-08) 2 commits
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
* tr/http-push-ref-status (2009-12-24) 6 commits
Daniel and Jeff commented on the earlier rounds; is everybody happy with
this v3? If so let's move it to 'next'. If not, please complain.
* jh/notes (2009-12-07) 11 commits
I didn't see any negative comments after this round; is everybody happy
with this? If so let's move it to 'next'. If not, please complain.
* sr/gfi-options (2009-12-04) 7 commits
I didn't see any negative comments after this round; is everybody happy
with this? If so let's move it to 'next'. If not, please complain.
----------------------------------------------------------------
I expect the following to be in 'master' by the end of next week.
* bg/maint-remote-update-default (2009-12-31) 1 commit
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
* jk/push-to-delete (2009-12-30) 1 commit
* mm/config-path (2009-12-30) 1 commit
* pm/cvs-environ (2009-12-30) 1 commit
* so/cvsserver-update (2009-12-07) 1 commit
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
* js/filter-branch-prime (2009-12-15) 1 commit
* mg/tag-d-show (2009-12-10) 1 commit
* sb/maint-octopus (2009-12-11) 3 commits
* bg/maint-add-all-doc (2009-12-07) 4 commits
* mv/commit-date (2009-12-03) 2 commits
* mo/bin-wrappers (2009-12-02) 3 commits
* tr/http-updates (2009-12-28) 4 commits
* nd/sparse (2009-12-30) 23 commits
----------------------------------------------------------------
These need a bit more work to go forward. Help and follow-up are
appreciated.
* jc/fix-tree-walk (2009-09-14) 7 commits
Resurrected from "Ejected" category. This is a fix to a tricky
codepath and testing and improving before it hits 'next' by brave souls
is greatly appreciated. I am not very happy about the solution myself.
* tc/clone-v-progress (2009-12-26) 4 commits
Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* jh/commit-status (2009-12-07) 1 commit
Needs tests.
* jc/checkout-merge-base (2009-11-20) 2 commits
Users of "rebase -i" might want to teach this to the command.
Volunteers?
* il/vcs-helper (2009-12-09) 8 commits
According to http://thread.gmane.org/gmane.comp.version-control.git/134980
this is very close to completion (or did I overlook a reroll after that?)
but the final touch is not there yet.
^ permalink raw reply
* Re: [PATCH/RFC] Add support for the google-chrome web browser
From: Junio C Hamano @ 2010-01-05 5:40 UTC (permalink / raw)
To: Evan Farrer; +Cc: git, Christian Couder
In-Reply-To: <20100105051906.GA22799@efarrerlx.appsig.com>
Evan Farrer <evan.farrer@gmail.com> writes:
> Signed-off-by: Evan Farrer <Evan.Farrer@gmail.com>
> ---
> Documentation/git-web--browse.txt | 1 +
> git-web--browse.sh | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
> index 278cf73..0994139 100644
> --- a/Documentation/git-web--browse.txt
> +++ b/Documentation/git-web--browse.txt
> @@ -25,6 +25,7 @@ The following browsers (or commands) are currently supported:
> * links
> * lynx
> * dillo
> +* google-chrome
Hmmm, the support added by this patch for the chrome is, together with
w3m, links, and open, to simply run the command with given arguments
without any other magic.
Perhaps valid_custom_tool() function should be changed to simply return $1
if $browser_cmd is not found, like this:
valid_custom_tool ()
{
browser_cmd=$(git config "browser.$1.cmd")
: ${browser_cmdn:=$1}
}
Then we don't even have to add any specific support for "google-chrome" or
anything that takes "$command $path..." and opens the documents.
Is there a downside in this approach?
^ permalink raw reply
* Re: "git add -i" with path gives "Argument list too long"
From: Junio C Hamano @ 2010-01-05 5:31 UTC (permalink / raw)
To: Jeff King; +Cc: Wincent Colaiuta, git
In-Reply-To: <20100105041438.GB12574@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I seem to recall Junio noting in the past the inconsistencies in git
> about what is a path and what is a pathspec. Is this one of those
> inconsistencies, and would it be a positive thing to fix it?
We actually never take paths and everything we take is pathspec. One
longstanding gripe I had around this area is there are two kinds of
pathspecs. "diff-tree" family of pathspecs only match "leading
directories" while "dir.c" and "builtin-grep.c" pathspecs allow both
"leading directories" and "glob" pathspecs. Teaching "diff-tree" family
to also grok globs would be a very nice thing to do, and the listing of
paths with ls-files in the sample patch you are removing is indeed a
workaround for this issue.
^ permalink raw reply
* [PATCH/RFC] Add support for the google-chrome web browser
From: Evan Farrer @ 2010-01-05 5:19 UTC (permalink / raw)
To: git; +Cc: Christian Couder
Signed-off-by: Evan Farrer <Evan.Farrer@gmail.com>
---
Documentation/git-web--browse.txt | 1 +
git-web--browse.sh | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
index 278cf73..0994139 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -25,6 +25,7 @@ The following browsers (or commands) are currently supported:
* links
* lynx
* dillo
+* google-chrome
* open (this is the default under Mac OS X GUI)
* start (this is the default under MinGW)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index a578c3a..0664b9e 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -31,7 +31,7 @@ valid_custom_tool()
valid_tool() {
case "$1" in
- firefox | iceweasel | konqueror | w3m | links | lynx | dillo | open | start)
+ firefox | iceweasel | konqueror | w3m | links | lynx | dillo | google-chrome | open | start)
;; # happy
*)
valid_custom_tool "$1" || return 1
@@ -103,7 +103,7 @@ fi
if test -z "$browser" ; then
if test -n "$DISPLAY"; then
- browser_candidates="firefox iceweasel konqueror w3m links lynx dillo"
+ browser_candidates="firefox iceweasel konqueror w3m links lynx dillo google-chrome"
if test "$KDE_FULL_SESSION" = "true"; then
browser_candidates="konqueror $browser_candidates"
fi
@@ -162,7 +162,7 @@ case "$browser" in
;;
esac
;;
- w3m|links|lynx|open)
+ w3m|links|lynx|google-chrome|open)
eval "$browser_path" "$@"
;;
start)
--
1.6.6.78.gbd757c
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-05 5:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20100105042046.GC12574@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:
>
>> > 1. My patch "t0021:..." contains an unrelated change to t4030 (it
>> > changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
>> > in my first version of the patch, but later noticed that we already
>> > have many similar uses of /bin/sh instead of $SHELL_PATH in test
>> > scriptlets and decided to remove the change, but I only changed the
>> > commit message and forgot to unstage t4030.
>>
>> While you are technically correct that the change you made in t4030 is not
>> justified by the commit log message in the sense that the "hexdump" script
>> will go through run_command() interface and is not subject to the special
>> rules filter writers need to keep in mind, the patch text itself is a good
>> change, isn't it? Do you want me to split the commit into two (one with
>> the current message with a patch only to t0021, and another to t4030 with
>> a justification like "SHELL_PATH is what the user told us to use")?
>
> If we are going to do the t4030 change, there are a ton of other spots
> that use /bin/sh directly (I counted 38 with
>
> grep -n /bin/sh * | grep -v :1:
>
> ). Should we be changing all of them?
>
> It is slightly just code churn, because the scripts are so simple that
> even broken shells like Solaris /bin/sh run them just fine. The only
> real advantage is that it slightly future-proofs them against somebody
> making them more complex.
Ok, it is a single liner that invokes Perl, so hardcoded /bin/sh is a much
lessor offence.
^ permalink raw reply
* Re: [updated patch v3 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2010-01-05 5:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ilari Liusvaara, git
In-Reply-To: <4B3CF568.1050705@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Ilari Liusvaara schrieb:
>> +static inline void force_close(int fd)
>> +{
>> + /*
>> + * The close is deemed success or failed in non-transient way if
>> + * close() suceeds, returns EBADF or error other than EINTR or
>> + * EAGAIN.
>> + */
>> + while (close(fd) < 0 && errno != EBADF)
>> + if(errno != EINTR && errno != EAGAIN)
>> + break;
>
> You are constantly ignoring proposals to iterate only on EINTR and
> EAGAIN, but do not make an argument why you do otherwise. Did I miss
> something?
Meaning something like this?
static inline void force_close(int fd)
{
/*
* Retry failed close() on EINTR or EAGAIN
*/
while (close(fd) < 0 && (errno == EINTR || errno == EAGAIN))
; /* try again */
}
which should be equivalent as long as EBADF is different from EINTR and
EAGAIN, I think.
>> + if (cmd->pid > 0) {
>> + int r = 0, ret;
>> + force_close(report_pipe[1]);
>> +read_again:
>> ...
>> + if(waitpid(cmd->pid, &ret, 0) < 0 && errno == EINTR)
>> + /* Nothing. */ ;
>> + cmd->pid = -1;
>
> As per Documentation/technical/api-run-command.txt, you should write
> an error here, except if (failed_errno==ENOENT &&
> cmd->silent_exec_failure!=0).
I was planning to replace the earlier series that was dropped from pu with
this iteration, but I guess I'll wait for another round before doing so.
Thanks for reviewing.
>> +test_expect_success "reporting ENOENT" \
>> +"test-run-command 1"
>
> I wonder what this parameter "1" is good for...
I guessed that this is for adding more tests to test-run-command in the
future and not having to change this test, in which case I think it is a
sensible thing to do.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-05 4:30 UTC (permalink / raw)
To: Russell Steicke; +Cc: git
In-Reply-To: <c1b8b6671001041852w4740b7d6g4b8db1221c5dc744@mail.gmail.com>
2010/1/5 Russell Steicke <russellsteicke@gmail.com>:
> On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
>> So i need to change the remote name manually.
>>
>> I tried modifying the .git/config file locally but it didn't work.
>>
>> Could someone help tell how to do it?
>
> After editing .git/config, do this:
>
> $ mv .git/refs/remotes/OLDNAME .git/refs/remotes/NEWNAME
>
> and optionally:
>
> $ mv .git/logs/refs/remotes/OLDNAME .git/logs/refs/remotes/NEWNAME
>
> Remember to rename the remote in any tracking branches in .git/config,
> as well as the name in the [remote "OLDNAME"] section, and the name in
> any fetch and push lines. ie
>
> [remote "OLDNAME"]
> url = something
> fetch = +refs/heads/*:refs/remotes/OLDNAME/*
> [branch "master"]
> remote = OLDNAME
> merge = refs/heads/master
>
> Becomes
>
> [remote "NEWNAME"]
> url = something
> fetch = +refs/heads/*:refs/remotes/NEWNAME/*
> [branch "master"]
> remote = NEWNAME
> merge = refs/heads/master
Thanks a lot, Russell.
I followed you instruction but it seemed it needs more changes.
Below are the steps:
Original:
root@ubuntu:/work/git-repo/free_monkey# tree -a
.
|-- .git
| |-- HEAD
| |-- branches
| |-- config
| |-- description
| |-- hooks
| | |-- applypatch-msg.sample
| | |-- commit-msg.sample
| | |-- post-commit.sample
| | |-- post-receive.sample
| | |-- post-update.sample
| | |-- pre-applypatch.sample
| | |-- pre-commit.sample
| | |-- pre-rebase.sample
| | |-- prepare-commit-msg.sample
| | `-- update.sample
| |-- index
| |-- info
| | `-- exclude
| |-- logs
| | |-- HEAD
| | `-- refs
| | |-- heads
| | | `-- master
| | `-- remotes
| | `-- origin
| | `-- HEAD
| |-- objects
| | |-- info
| | `-- pack
| | |-- pack-f4beae76253ca8d36af31c42320462b5cf4940fc.idx
| | `-- pack-f4beae76253ca8d36af31c42320462b5cf4940fc.pack
| |-- packed-refs
| `-- refs
| |-- heads
| | `-- master
| |-- remotes
| | `-- origin
| | `-- HEAD
| `-- tags
`-- hello1
root@ubuntu:/work/git-repo/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
root@ubuntu:/work/git-repo/free_monkey#
Execute your steps....
Becomes:
root@ubuntu:/work/git-repo/free_monkey# tree -a
.
|-- .git
| |-- HEAD
| |-- branches
| |-- config
| |-- description
| |-- hooks
| | |-- applypatch-msg.sample
| | |-- commit-msg.sample
| | |-- post-commit.sample
| | |-- post-receive.sample
| | |-- post-update.sample
| | |-- pre-applypatch.sample
| | |-- pre-commit.sample
| | |-- pre-rebase.sample
| | |-- prepare-commit-msg.sample
| | `-- update.sample
| |-- index
| |-- info
| | `-- exclude
| |-- logs
| | |-- HEAD
| | `-- refs
| | |-- heads
| | | `-- master
| | `-- remotes
| | `-- karmic
| | `-- HEAD
| |-- objects
| | |-- info
| | `-- pack
| | |-- pack-f4beae76253ca8d36af31c42320462b5cf4940fc.idx
| | `-- pack-f4beae76253ca8d36af31c42320462b5cf4940fc.pack
| |-- packed-refs
| `-- refs
| |-- heads
| | `-- master
| |-- remotes
| | `-- karmic
| | `-- HEAD
| `-- tags
`-- hello1
root@ubuntu:/work/git-repo/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "karmic"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/remotes/karmic/*
[branch "master"]
remote = karmic
merge = refs/heads/master
But the result was:
root@ubuntu:/work/git-repo/free_monkey# git branch -a
* master
karmic/HEAD
origin/master
The 'origin/master' was still not changed.
I did a few more steps:
root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
refs/remotes/origin/master
./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
Change 'origin' to 'karmic' in above files.
Then,
root@ubuntu:/work/git-repo/free_monkey# git branch -a
* master
karmic/HEAD
karmic/master
The steps are a little complicated.
Do you know if there's a way to rename the remote on server side?
If there is, then everyone could just clone the project with a new
remote name rather than the defaul 'origin'.
Thanks
Regards
Dongas
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Jeff King @ 2010-01-05 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vhbr1bagk.fsf@alter.siamese.dyndns.org>
On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:
> > 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> > changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> > in my first version of the patch, but later noticed that we already
> > have many similar uses of /bin/sh instead of $SHELL_PATH in test
> > scriptlets and decided to remove the change, but I only changed the
> > commit message and forgot to unstage t4030.
>
> While you are technically correct that the change you made in t4030 is not
> justified by the commit log message in the sense that the "hexdump" script
> will go through run_command() interface and is not subject to the special
> rules filter writers need to keep in mind, the patch text itself is a good
> change, isn't it? Do you want me to split the commit into two (one with
> the current message with a patch only to t0021, and another to t4030 with
> a justification like "SHELL_PATH is what the user told us to use")?
If we are going to do the t4030 change, there are a ton of other spots
that use /bin/sh directly (I counted 38 with
grep -n /bin/sh * | grep -v :1:
). Should we be changing all of them?
It is slightly just code churn, because the scripts are so simple that
even broken shells like Solaris /bin/sh run them just fine. The only
real advantage is that it slightly future-proofs them against somebody
making them more complex.
-Peff
^ permalink raw reply
* Re: "git add -i" with path gives "Argument list too long"
From: Jeff King @ 2010-01-05 4:14 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <36FEB8A0-968D-4B43-AEFB-9B0E227A1F88@wincent.com>
[cc'd Junio: there is a question of path limiters versus pathspecs near
the bottom].
On Mon, Jan 04, 2010 at 07:43:10PM +0100, Wincent Colaiuta wrote:
> Just ran "git add -i <path>" with "<path>" pointing to a subdirectory
> which happens to have a bunch of files in it (about 7k) and it barfed
> thusly:
>
> Can't exec "git": Argument list too long at /usr/local/libexec/git-
> core/git-add--interactive line 158.
> Died at /usr/local/libexec/git-core/git-add--interactive line 158.
>
> I see that what it's trying to do under the hood is:
>
> git diff-index --cached --numstat --summary HEAD -- <7,000+ paths...>
Yep, and there is a similar diff-files call after that.
> Sure, we could divide the paths into smaller groups, run multiple
> invocations of "git diff-index", and concatenate the results. But it
> would be nicer if there was some other way that we could get at the
> same information without having to pass 7,000 paths explicitly on the
> command line; is there any which I am overlooking?
No, I don't think there is way to do it with the current code short of
breaking up the output.
> The enormous file list is the result of passing <path> into "git ls-
> files -- <path>". Would it be worth:
>
> - either, modifying "git diff-index" to accept a list of paths over
> stdin so that we could at least pipe the output from "git ls-files"
> into "git diff-index"
We could do that. It would also need a patch for diff-files. And
unfortunately it makes their interface somewhat inconsistent then with
diff-tree, which already has a --stdin but uses it for a list of
tree-ishes.
> - or, preferably, teach "git diff index" to recurse into directories
> rather than expect a list of paths-of-blobs (possibly with a command
> line switch to activate the behaviour if it were deemed a dangerous
> default)
Doesn't it already do this? If I say "git diff index subdir" it
will limit the diff only to things inside subdir/.
In fact, it is tempting to do this:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index bfd1003..a8b3e30 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -275,15 +275,6 @@ sub list_modified {
my ($only) = @_;
my (%data, @return);
my ($add, $del, $adddel, $file);
- my @tracked = ();
-
- if (@ARGV) {
- @tracked = map {
- chomp $_;
- unquote_path($_);
- } run_cmd_pipe(qw(git ls-files --), @ARGV);
- return if (!@tracked);
- }
my $reference;
if (defined $patch_mode_revision and $patch_mode_revision ne 'HEAD') {
@@ -295,7 +286,7 @@ sub list_modified {
}
for (run_cmd_pipe(qw(git diff-index --cached
--numstat --summary), $reference,
- '--', @tracked)) {
+ '--', @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
my ($change, $bin);
@@ -320,7 +311,7 @@ sub list_modified {
}
}
- for (run_cmd_pipe(qw(git diff-files --numstat --summary --), @tracked)) {
+ for (run_cmd_pipe(qw(git diff-files --numstat --summary --), @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
$file = unquote_path($file);
but note that the pathspecs given to ls-files and the path limiters
given to diff are not quite the same. So "git add -i '*.c'" will
currently find "subdir/foo.c", but would not with the above patch. Is
that what you meant when you said "recurse into directories"?
I seem to recall Junio noting in the past the inconsistencies in git
about what is a path and what is a pathspec. Is this one of those
inconsistencies, and would it be a positive thing to fix it?
-Peff
^ permalink raw reply related
* Re: A question about changing remote repo name
From: Russell Steicke @ 2010-01-05 2:52 UTC (permalink / raw)
To: Dongas; +Cc: git
In-Reply-To: <60ce8d251001032245n4e0267b1o1ecc796f324f8179@mail.gmail.com>
On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
> So i need to change the remote name manually.
>
> I tried modifying the .git/config file locally but it didn't work.
>
> Could someone help tell how to do it?
After editing .git/config, do this:
$ mv .git/refs/remotes/OLDNAME .git/refs/remotes/NEWNAME
and optionally:
$ mv .git/logs/refs/remotes/OLDNAME .git/logs/refs/remotes/NEWNAME
Remember to rename the remote in any tracking branches in .git/config,
as well as the name in the [remote "OLDNAME"] section, and the name in
any fetch and push lines. ie
[remote "OLDNAME"]
url = something
fetch = +refs/heads/*:refs/remotes/OLDNAME/*
[branch "master"]
remote = OLDNAME
merge = refs/heads/master
Becomes
[remote "NEWNAME"]
url = something
fetch = +refs/heads/*:refs/remotes/NEWNAME/*
[branch "master"]
remote = NEWNAME
merge = refs/heads/master
--
Virus found in this message.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-05 2:25 UTC (permalink / raw)
To: kusmabite; +Cc: Miklos Vajna, git
In-Reply-To: <40aa078e1001041757q137c9d1erf8f6793016d6a2c2@mail.gmail.com>
2010/1/5 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Tue, Jan 5, 2010 at 2:53 AM, Dongas <dongas86@gmail.com> wrote:
>> 2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
>>> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>>>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>>>> support git remote rename command.
>>>
>>> It first appeared in v1.6.1, about a year ago. What does 'git version'
>>> say?
>>
>> Thanks a lot for your reply.
>>
>> # git --version
>> git version 1.6.0.4
>>
>> It seems the ubuntu9.04 doesn't have the repo source to update to a
>> higher git version than 1.6.0.4,
>> i'd like to know if there's a manual way to rename the git remote name
>> with this version.
>>
>
> I know this isn't REALLY answering your question, but you should
> seriously consider upgrading. 1.6.0.4 is ancient.
>
Thanks a lot for your advices.
Unfortunately, all my team members are running ubuntu 9.04.
If i could find a easy way to upgrade it, it will take it.
Regards
Dongas
^ permalink raw reply
* Re: cannot remove remote branch name
From: Junio C Hamano @ 2010-01-05 2:18 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <hhu694$3v9$1@ger.gmane.org>
SungHyun Nam <goweol@gmail.com> writes:
> How I can remove remote branch name if it already removed
> in remote side?
>
> $ git branch -a
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/master
> remotes/origin/test
> $ git branch -D -r test
> error: remote branch 'test' not found.
> $ git branch -D -r remotes/origin/test
> error: remote branch 'remotes/origin/test' not found.
> $ git branch -D remotes/origin/test
> error: branch 'remotes/origin/test' not found.
Hmm, you tried "test" and then "remotes/origin/test"?
The way I would have guessed what to give the command is:
1. "branch -D -r test" wouldn't make sense, as git wouldn't know 'test'
of which remote I am trying to remove;
2. "-r" already tells git that I am talking about remote, so perhaps
"branch -D -r origin/test" would work without me saying "remotes/".
"git branch -[dD]" doesn't go over the network, so it doesn't matter if it
is already removed on the remote side or not.
^ permalink raw reply
* Re: cannot remove remote branch name
From: Erik Faye-Lund @ 2010-01-05 1:59 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <hhu694$3v9$1@ger.gmane.org>
On Tue, Jan 5, 2010 at 2:57 AM, SungHyun Nam <goweol@gmail.com> wrote:
> Hello,
>
> How I can remove remote branch name if it already removed
> in remote side?
>
> $ git branch -a
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/master
> remotes/origin/test
> $ git branch -D -r test
> error: remote branch 'test' not found.
> $ git branch -D -r remotes/origin/test
> error: remote branch 'remotes/origin/test' not found.
> $ git branch -D remotes/origin/test
> error: branch 'remotes/origin/test' not found.
>
> The 'remotes/origin/test' was removed in remote side.
>
$ git remote prune origin
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: A question about changing remote repo name
From: Erik Faye-Lund @ 2010-01-05 1:57 UTC (permalink / raw)
To: Dongas; +Cc: Miklos Vajna, git
In-Reply-To: <60ce8d251001041753y5fe37b9do8d4cffc477e58198@mail.gmail.com>
On Tue, Jan 5, 2010 at 2:53 AM, Dongas <dongas86@gmail.com> wrote:
> 2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
>> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>>> support git remote rename command.
>>
>> It first appeared in v1.6.1, about a year ago. What does 'git version'
>> say?
>
> Thanks a lot for your reply.
>
> # git --version
> git version 1.6.0.4
>
> It seems the ubuntu9.04 doesn't have the repo source to update to a
> higher git version than 1.6.0.4,
> i'd like to know if there's a manual way to rename the git remote name
> with this version.
>
I know this isn't REALLY answering your question, but you should
seriously consider upgrading. 1.6.0.4 is ancient.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* cannot remove remote branch name
From: SungHyun Nam @ 2010-01-05 1:57 UTC (permalink / raw)
To: git
Hello,
How I can remove remote branch name if it already removed
in remote side?
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/test
$ git branch -D -r test
error: remote branch 'test' not found.
$ git branch -D -r remotes/origin/test
error: remote branch 'remotes/origin/test' not found.
$ git branch -D remotes/origin/test
error: branch 'remotes/origin/test' not found.
The 'remotes/origin/test' was removed in remote side.
Thanks,
namsh
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-05 1:53 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20100104200908.GS29803@genesis.frugalware.org>
2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>> support git remote rename command.
>
> It first appeared in v1.6.1, about a year ago. What does 'git version'
> say?
Thanks a lot for your reply.
# git --version
git version 1.6.0.4
It seems the ubuntu9.04 doesn't have the repo source to update to a
higher git version than 1.6.0.4,
i'd like to know if there's a manual way to rename the git remote name
with this version.
Regards
Dongas
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-05 1:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B421766.4040506@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Junio C Hamano schrieb:
>> * jk/run-command-use-shell (2010-01-01) 8 commits
>> - t4030, t4031: work around bogus MSYS bash path conversion
>> - t0021: use $SHELL_PATH for the filter script
>> - diff: run external diff helper with shell
>> - textconv: use shell to run helper
>> - editor: use run_command's shell feature
>> - run-command: optimize out useless shell calls
>> - run-command: convert simple callsites to use_shell
>> - run-command: add "use shell" option
>
> Two notes about this:
>
> 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> in my first version of the patch, but later noticed that we already
> have many similar uses of /bin/sh instead of $SHELL_PATH in test
> scriptlets and decided to remove the change, but I only changed the
> commit message and forgot to unstage t4030.
While you are technically correct that the change you made in t4030 is not
justified by the commit log message in the sense that the "hexdump" script
will go through run_command() interface and is not subject to the special
rules filter writers need to keep in mind, the patch text itself is a good
change, isn't it? Do you want me to split the commit into two (one with
the current message with a patch only to t0021, and another to t4030 with
a justification like "SHELL_PATH is what the user told us to use")?
> 2. If you intend to merge the early part of the topic to master early
> and hold "diff:..." and "textconv:..." in next a bit longer (as
> proposed by Jeff), then you should move "t0021:..." after
> "run-command: optimize out useless shell calls".
As "run-command: convert simple callsites to use_shell" is the one that
changes the filter_buffer(), do you want to have t0021 patch before that
one, to prepare the test for the coming change?
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Avery Pennarun @ 2010-01-04 22:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
On Mon, Jan 4, 2010 at 5:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Mon, 4 Jan 2010, Jens Lehmann wrote:
>> IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
>> to include another git repo. And it gives the reproducibility i expect
>> from a scm. Or am i missing something?
>
> You do remember the discussion at the Alles wird Git about the need for
> Subversion external-like behavior, right?
I'm not sure why this is such an issue. Basically, non-version-locked
submodules are about the easiest thing in the world; that's why CVS
and SVN supported them first. (SVN later added version-locking like
git has.)
All you need is a .gitignore entry and a trivial script that checks
out the external. If you want to be fancy, this operation could be
part of git, but it's such a totally different case (and an easy one,
no less) that I think it ought to be treated totally seperately.
> - among other use cases, submodules are recommended for sharing content
> between two different repositories. But it is part of the design that it
> is _very_ easy to forget to commit, or push the changes in the submodule
> that are required for the integrity of the superproject.
[...]
> - working directories with GIT_DIRs are a very different beast from single
> files. That alone leads to a _lot_ of problems. The original design of
> Git had only a couple of states for named content (AKA files): clean,
> added, removed, modified. The states that are possible with submodules
> are for the most part not handled _at all_ by most Git commands (and it
> is sometimes very hard to decide what would be the best way to handle
> those states, either). Just think of a submodule at a different
> revision than committed in the superproject, with uncommitted changes,
> ignored and unignored files, a few custom hooks, a bit of additional
> metadata in the .git/config, and just for fun, a few temporary files in
> .git/ which are used by the hooks.
I think this is primarily because checked-out submodules currently
have their own .git directories (with their own config, index, etc).
If they were considered *part* of the subproject's repo checkout, and
updated upon switching branches, etc, this whole class of problems
would go away.
> - that use case -- sharing content between different repositories -- is
> not really supported by submodules, but rather an afterthought. This is
> all too obvious when you look at the restriction that the shared content
> must be in a single subdirectory.
I haven't found the subdir requirement to be much of an issue, at
least on Unix where I can simply work around it using symlinks from
the superproject into the subproject. It's obviously more gross on
Windows, but I've worked around it there too. This one isn't a daily
aggravation for me, though maybe it is for others. And any cure I can
think of sounds rather worse than the disease.
> - submodules would be a perfect way to provide a fast-forward-only media
> subdirectory that is written to by different people (artists) than to
> the superproject (developers). But there is no mechanism to enforce
> shallow fetches, which means that this use case cannot be handled
> efficiently using Git.
I doubt you want to "enforce" shallow fetches. And if you just want
to "allow" shallow fetches, or default to shallow fetches, I'd think
it would be pretty easy to add. This hasn't been important to me
either. (It seems to be not too important to git users in general, or
git's support *in general* for shallow repositories would be more
featureful.)
> - while it might be called clever that the submodules' metadata are stored
> in .gitmodules in the superproject (and are therefore naturally tracked
> with Git), the synchronization with .git/config is performed exactly
> once -- when you initialize the submodule. You are likely to miss out
> on _every_ change you pulled into the superproject.
This could be fixed too, though I gave up on git-submodule before I
bothered to fix it myself.
The correct solution here is simply to not ever copy the settings from
.gitmodules into .git/config. Instead, git-submodule should read
.gitmodules as defaults, and then override those defaults with
anything in .git/config. 99% of users will probably not need to ever
put any of their settings in .git/config, and so this problem
disappears.
> All in all, submodules are very clumsy to work with, and you are literally
> forced to provide scripts in the superproject to actually work with the
> submodules.
Agreed; I do this in every project which uses git-submodule. (And
from doing so, I learned that the value-added of git-submodule is
nearly zero. My script does most of the work, and it could just as
easily check out the submodule as a git repo too. I could even choose
to version-lock or not version-lock the checked-out submodule: just
hardcode the commitid into my script!)
> I do not think that --include-submodules is a good default. It is just
> too expensive in terms of I/O even to check the status in a superproject
> with a lot of submodules.
I've thought about this a lot, and I think having a special case for
submodules here is the wrong line of thinking. A big project
*without* submodules has this same problem. The "real" solution is to
just make status checks faster.
(This is actually possible to do: in the extreme case, you just have a
daemon running with inotify or the Windows equivalent. TortoiseSvn
reputedly does something like this. I've thought of writing such a
daemon myself to just twiddle --assume-{un,}changed flags at the right
times, particularly since status checks in Windows are so ridiculously
slow. But I got frustrated when it was *still* slow even after
setting --assume-unchanged on all the files in the index. git still
scans directories to detect *unknown* files, and there seems to be no
way to turn it off or, moreover, to provide the list of unknown files
from some other source.)
Have fun,
Avery
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Sverre Rabbelier @ 2010-01-04 22:52 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu2zl4tfuij.fsf@nowhere.com>
Heya,
On Mon, Jan 4, 2010 at 16:08, Adam Megacz <adam@megacz.com> wrote:
> Perhaps a preference (off by default) demanding that they be set
> explicitly when "git commit -m" is used?
Heh, what use would that be? On a different/new box you would have
neither that setting nor the email set, so that doens't solve the
problem methinks :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Avery Pennarun @ 2010-01-04 22:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Jens Lehmann, Git Mailing List,
Junio C Hamano, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <20100104222701.GE22872@spearce.org>
On Mon, Jan 4, 2010 at 5:27 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Besides, as long as there is enough reason to have out-of-Git alternative
>> solutions such as repo, submodules deserve to be 2nd-class citizens.
>
> If I didn't think I'd be shot by current submodule users, I'd offer
> to write a full replacement based around the current in repository
> format, but with sane features like we have in repo.
Perhaps write it and call it 'git sub' or something. Put them both
in, and let users decide which they want to use. Or, like git
subtree, maintain it separately.
Personally, I've avoided tools like repo because they seem to try to
kidnap my *entire* git experience, most of which is already fine.
It's just submodules that are crazy. I think it's probably similar
for other people.
Avery
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Shawn O. Pearce @ 2010-01-04 22:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Besides, as long as there is enough reason to have out-of-Git alternative
> solutions such as repo, submodules deserve to be 2nd-class citizens.
If I didn't think I'd be shot by current submodule users, I'd offer
to write a full replacement based around the current in repository
format, but with sane features like we have in repo.
Actually, that's why repo happened. I felt like submodules was
already too frozen to accept a different approach. And another
guy here thought XML might be a solution to a problem... :-|
--
Shawn.
^ permalink raw reply
* submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 22:29 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B421F90.4090402@web.de>
Hi,
On Mon, 4 Jan 2010, Jens Lehmann wrote:
> Am 04.01.2010 10:44, schrieb Johannes Schindelin:
> > The real problem is that submodules in the current form are not very
> > well designed.
>
> IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
> to include another git repo. And it gives the reproducibility i expect
> from a scm. Or am i missing something?
You do remember the discussion at the Alles wird Git about the need for
Subversion external-like behavior, right?
> It looks to me as most shortcomings come from the fact that most git
> commands tend to ignore submodules (and if they don't, like git gui and
> gitk do now, they e.g. only show certain aspects of their state).
It is not only ignoring. It is not being able to cope with the state only
submodules can be in (see below).
> Submodules are in heavy use in our company since last year. Virtually
> every patch i submitted for submodules came from that experience and
> scratched an itch i or one of my colleagues had (and the situation did
> already improve noticeably by the few things we changed). We are still
> convinced that using submodules was the right decision. But some work
> has still to be done to be able to use them easily and to get rid of
> some pitfalls.
Submodules may be the best way you have in Git for your workflow ATM.
But that does not mean that the submodule design is in any way
thought-through.
Just a few shortcomings that do show up in my main project (and to a
small extent in msysGit, as you are probably aware):
- submodules were designed with a strong emphasis on not being forced to
check them out. But Git makes it very unconvenient to actually check
submodules out, let alone check them out at clone-time. And it is
outright impossible to _enforce_ a submodule to be checked out.
- among other use cases, submodules are recommended for sharing content
between two different repositories. But it is part of the design that it
is _very_ easy to forget to commit, or push the changes in the submodule
that are required for the integrity of the superproject.
- that use case -- sharing content between different repositories -- is
not really supported by submodules, but rather an afterthought. This is
all too obvious when you look at the restriction that the shared content
must be in a single subdirectory.
- submodules would be a perfect way to provide a fast-forward-only media
subdirectory that is written to by different people (artists) than to
the superproject (developers). But there is no mechanism to enforce
shallow fetches, which means that this use case cannot be handled
efficiently using Git.
- related are the use cases where it is desired not to have a fixed
submodule tip committed to the superproject, but always to update to the
current, say, master (like Subversion's externals). This use case has
been wished away by the people who implemented submodules in Git. But
reality has this nasty habit of ignoring your wishes, does it not?
- there have been patches supporting rebasing submodules, i.e.
submodules where a "git submodule update" rebases the current branch to
the revision committed to the superproject rather than detaching the
HEAD, which everybody who ever contributed to a project with submodules
should agree is a useful thing. But the patches only have been discussed
to death, to the point where the discussion's information content was
converging to zero, yet the patches did not make it into Git. (FWIW
this is one reason why I refuse to write patches to git-submodule.sh: I
refuse to let my time to be wasted like that.)
- working directories with GIT_DIRs are a very different beast from single
files. That alone leads to a _lot_ of problems. The original design of
Git had only a couple of states for named content (AKA files): clean,
added, removed, modified. The states that are possible with submodules
are for the most part not handled _at all_ by most Git commands (and it
is sometimes very hard to decide what would be the best way to handle
those states, either). Just think of a submodule at a different
revision than committed in the superproject, with uncommitted changes,
ignored and unignored files, a few custom hooks, a bit of additional
metadata in the .git/config, and just for fun, a few temporary files in
.git/ which are used by the hooks.
- while it might be called clever that the submodules' metadata are stored
in .gitmodules in the superproject (and are therefore naturally tracked
with Git), the synchronization with .git/config is performed exactly
once -- when you initialize the submodule. You are likely to miss out
on _every_ change you pulled into the superproject.
All in all, submodules are very clumsy to work with, and you are literally
forced to provide scripts in the superproject to actually work with the
submodules.
> > In ths short run, we can paper over the shortcomings of the submodules
> > by introducing a command line option "--include-submodules" to
> > update-refresh, diff-files and diff-index, though.
>
> Maybe this is the way to go for now (and hopefully we can turn this
> option on by default later because we did the right thing ;-).
I do not think that --include-submodules is a good default. It is just
too expensive in terms of I/O even to check the status in a superproject
with a lot of submodules.
Besides, as long as there is enough reason to have out-of-Git alternative
solutions such as repo, submodules deserve to be 2nd-class citizens.
Ciao,
Dscho
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Adam Megacz @ 2010-01-04 21:08 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e1001041232h4e5827d1pb5c648b33ecfb5ce@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Jan 3, 2010 at 18:32, Adam Megacz <adam@megacz.com> wrote:
>> I've been having problems lately with running git on machines where
>> I forgot to set up my .gitconfig; I wind up with patches that have
>> committers like root@mymachine and so forth. Being automatically
>> shown the committer/author when I make the commit would help me
>> avoid these situations.
>
> At the very least it should be easy to include these fields as
> comments in the message template.
That would be great.
> But of course you would still be bitten if you used "git commit -m"
> :(.
Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?
Some people care more than others about the metadata; this is for the
folks to whom it matters a lot.
- a
^ 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