* Re: Workflow question
From: Junio C Hamano @ 2007-09-26 5:29 UTC (permalink / raw)
To: Russ Brown; +Cc: Jeff King, git
In-Reply-To: <46F9CA2A.7000107@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> I'm just wondering at this point why git lets you checkout remote
> tracking branches if it's something you really shouldn't do. Unless it's
> something you want to be able to do in edge cases to fix screwups maybe?
You actually never checkout "remote tracking branches".
You can be in two states, either you are on a branch (meaning,
if you create a commit, the new commit will have the current tip
commit of that branch as its first parent and will become the
new tip commit of that branch), or you aren't on _any_ branch.
The latter state is often affectionately called "detached HEAD"
state.
This is primarily useful for sightseeing. Sometimes people
would want to check out a commit that is not a tip of any
branch. The most typical one is "I want to have a checkout of
version 2.6.17", and people call that (loosely) as "checking out
a tag". In the same way, you can "checkout a remote tracking
branch" (but if you want to be anal in terminology, you never
"check out a tag" nor "check out a remote branch"---you are
detaching your HEAD at the named commit (which could be the one
pointed at by the tag, or the one at the tip of your remote
tracking branch).
Detached HEAD state allows you to make further commits and
merges. Because git allows you to create a new branch from the
current commit (i.e. whatever HEAD points at, be it on any
branch or detached) without losing local changes in the index
nor the work tree, this is often handy for doing quick fixups and
experiments --- you first start on detached HEAD and if it turns
out not to be so "quick" fixup, at that point you can create a
real branch so that you can continue working on it without
losing track.
> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.
"Everyday" might be a good starting point for catalogs of
workflows for people playing various roles.
^ permalink raw reply
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Andreas Ericsson @ 2007-09-26 7:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Glenn Rempe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709260239210.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Sep 2007, Glenn Rempe wrote:
>
>>> * The indentation was horrible. Maybe your tabstop is set
>>> incorrectly?
>> Can you be more detailed on the definition of 'horrible'? :-) I am using
>> Textmate on OS X with soft tab stops (2 spaces). What should it be to
>> look less horrible on your end? Or is the issue that I indent fewer
>> tabstops than you expect? If so, sorry since perl is not my usual
>> language and Ruby 2 space (soft tab) indentation looks right to my eye.
>
> We use soft tabs, with the standard up-to 8 spaces,
Actually, the rest of git's perl-scripts use hard tabs, just as the C-code
and the shell-code, with tabs for indentation and spaces for alignment.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* question about git-send-email
From: Miklos Vajna @ 2007-09-26 7:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
hi,
maybe i do not use git-send-email as it's expected so here is my
workflow for a patch:
1) git format-patch
2) add additional comments between --- and diffstat
3) add to the patch
4) add cc the patch
5) add in-reply-to to the patch
6) invoke git send-email
2), 4) and 5) are read properly from the edited patch, but it asks again
for 3). it seems it asks for the to field before it parses the mail.
even worse, then it sends the mail with duplicated 'to' header if one
was in the mail already.
i tried to fix it but it doesn't seem to be so trivial to me and i'm not
a perl wizard :)
also i'm not sure if this usage is ok or not. just i think it's a bit
confusing that 'cc' is read from the patch, but 'to'.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Make builtin-rerere use of strbuf nicer and more efficient.
From: Pierre Habouzit @ 2007-09-26 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3ax22rnw.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On mer, sep 26, 2007 at 12:31:47 +0000, Junio C Hamano wrote:
> Signoffs?
This is obviously a lapse on my end. You can add:
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
To any patch I send to this list.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] t6000lib: workaround a possible dash bug
From: Herbert Xu @ 2007-09-26 8:41 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20070921204511.GA10079@muzzle>
On Fri, Sep 21, 2007 at 01:45:11PM -0700, Eric Wong wrote:
>
> I tried to reproduce it on a quick script using shell functions,
> multiple arguments, spaces in the $a variable.., but haven't
> been successful. However, reverting the below patch still
> causes errors in the latest git test suite.
Ah I see, it's a function. Unfortunately POSIX requires
shell functions to have the variable assignment properties
of special built-ins. So
X=value func
has the same properties as
X=value :
In other words, the value assigned to X (and any subsequent
values assigned within the function) persists after the call.
Also, the variable X is not exported unless it's already been
exported.
This is pretty lame but it's how the original Korn shell did
things and POSIX has adopted that. Bash's POSIX mode tries
to balance things by both making the value persist and exporting
X. Unfortunately this is buggy too as it causes X to continue
to be exported after the function returns.
So the bottom-line is that your patch is the correct solution
after all :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] Add a --dateformat= option to git-for-each-ref
From: Andy Parkins @ 2007-09-26 9:09 UTC (permalink / raw)
To: git
I wanted to get date information in RFC2822 format out of a tag using
git-for-each-ref; but there was no way to specify that. This patch
addresses that omission by adding a --dateformat option.
For example (I'm in BST, +0100 at present):
$ git-for-each-ref --dateformat=normal --format='%(taggerdate)' refs/tags/v1.5.2
Sun May 20 00:30:42 2007 -0700
$ git-for-each-ref --dateformat=relative --format='%(taggerdate)' refs/tags/v1.5.2
4 months ago
$ git-for-each-ref --dateformat=short --format='%(taggerdate)' refs/tags/v1.5.2
2007-05-20
$ git-for-each-ref --dateformat=local --format='%(taggerdate)' refs/tags/v1.5.2
Sun May 20 08:30:42 2007
$ git-for-each-ref --dateformat=iso8601 --format='%(taggerdate)' refs/tags/v1.5.2
2007-05-20 00:30:42 -0700
$ git-for-each-ref --dateformat=rfc2822 --format='%(taggerdate)' refs/tags/v1.5.2
Sun, 20 May 2007 00:30:42 -0700
The default is to use 'normal', which leaves existing behaviour
unchanged.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-for-each-ref.txt | 6 ++++++
builtin-for-each-ref.c | 18 +++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 6df8e85..1b8fdb8 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git-for-each-ref' [--count=<count>]\*
[--shell|--perl|--python|--tcl]
+ [--dateformat=normal|relative|short|local|iso8601|rfc2822]
[--sort=<key>]\* [--format=<format>] [<pattern>]
DESCRIPTION
@@ -58,6 +59,11 @@ OPTIONS
the specified host language. This is meant to produce
a scriptlet that can directly be `eval`ed.
+--dateformat::
+ If given, all timestamp fields will be output in the specified
+ format. This is only really relevant for innvocations using the
+ --format option with a `%(date)`-type field.
+
FIELD NAMES
-----------
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 0afa1c5..80e58fc 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -80,6 +80,7 @@ static struct {
static const char **used_atom;
static cmp_type *used_atom_type;
static int used_atom_cnt, sort_atom_limit, need_tagged;
+static enum date_mode date_mode = DATE_NORMAL;
/*
* Used to parse format string and sort specifiers
@@ -362,7 +363,7 @@ static void grab_date(const char *buf, struct atom_value *v)
tz = strtol(zone, NULL, 10);
if ((tz == LONG_MIN || tz == LONG_MAX) && errno == ERANGE)
goto bad;
- v->s = xstrdup(show_date(timestamp, tz, 0));
+ v->s = xstrdup(show_date(timestamp, tz, date_mode));
v->ul = timestamp;
return;
bad:
@@ -870,6 +871,21 @@ int cmd_for_each_ref(int ac, const char **av, const char *prefix)
sort->atom = parse_atom(arg, arg+len);
continue;
}
+ if (!prefixcmp(arg, "--dateformat=")) {
+ arg += 13;
+ if (!prefixcmp(arg,"relative")) {
+ date_mode = DATE_RELATIVE;
+ } else if (!prefixcmp(arg,"short")) {
+ date_mode = DATE_SHORT;
+ } else if (!prefixcmp(arg,"local")) {
+ date_mode = DATE_LOCAL;
+ } else if (!prefixcmp(arg,"iso8601")) {
+ date_mode = DATE_ISO8601;
+ } else if (!prefixcmp(arg,"rfc2822")) {
+ date_mode = DATE_RFC2822;
+ }
+ continue;
+ }
break;
}
if (quote_style < 0)
--
1.5.3.1.5.g4e560-dirty
^ permalink raw reply related
* Re: [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Johannes Schindelin @ 2007-09-26 10:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Glenn Rempe, Junio C Hamano, git
In-Reply-To: <46FA07B9.4000402@op5.se>
Hi,
On Wed, 26 Sep 2007, Andreas Ericsson wrote:
> Actually, the rest of git's perl-scripts use hard tabs, just as the
> C-code and the shell-code, with tabs for indentation and spaces for
> alignment.
D'oh. I meant to say hard tabs.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Sixt @ 2007-09-26 10:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0709251643310.28395@racer.site>
Johannes Schindelin schrieb:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 445a299..e3e89dd 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -174,7 +174,11 @@ pick_one_preserving_merges () {
> eval "$author_script"
> msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
> # NEEDSWORK: give rerere a chance
> - if ! output git merge $STRATEGY -m "$msg" $new_parents
> + if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> + output git merge $STRATEGY -m "$msg" \
> + $new_parents
> then
> printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
> die Error redoing merge $sha1
> @@ -281,7 +285,9 @@ do_next () {
> f)
> # This is like --amend, but with a different message
> eval "$author_script"
> - export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
> + GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> ;;
> t)
According to Herbert Xu's recent post
(http://article.gmane.org/gmane.comp.version-control.git/59219) this won't
export the variables in all shells since 'output' is a shell function. :-(
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Schindelin @ 2007-09-26 10:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <46FA358E.40500@viscovery.net>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 445a299..e3e89dd 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -174,7 +174,11 @@ pick_one_preserving_merges () {
> > eval "$author_script"
> > msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
> > # NEEDSWORK: give rerere a chance
> > - if ! output git merge $STRATEGY -m "$msg"
> > $new_parents
> > + if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > + output git merge $STRATEGY -m "$msg" \
> > + $new_parents
> > then
> > printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
> > die Error redoing merge $sha1
> > @@ -281,7 +285,9 @@ do_next () {
> > f)
> > # This is like --amend, but with a different message
> > eval "$author_script"
> > - export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> > GIT_AUTHOR_DATE
> > + GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > ;;
> > t)
>
> According to Herbert Xu's recent post
> (http://article.gmane.org/gmane.comp.version-control.git/59219) this won't
> export the variables in all shells since 'output' is a shell function. :-(
Argh.
You know, I am _so_ close to just scrap it and rewrite it in C.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Sixt @ 2007-09-26 11:18 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <86zlz9smqr.fsf@lola.quinscape.zz>
David Kastrup schrieb:
> If $USE_OUTPUT can be either shell function or executable or shell
> function plus args, however...
UTSL: $USE_OUTPUT is either 'output' (ie. a shell function) or empty.
-- Hannes
^ permalink raw reply
* [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 12:11 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
This allows a poor-mans-filter-branch of the top-most commit.
Specifically, I had this history:
--o--o--A' <-- amended version of A
\
A
\
--o--B--M
I now wanted to "amend" M to pull in A' instead of A as its second parent.
For various reasons I didn't want to redo the merge M again, in particular,
it already contained the changes that were amended into A'. So I figured
I would just install a graft that lists B and A' as parents of M and then
do a simple git commit --amend. Alas, git commit looks at the real parents
instead of the grafted ones, so the amended M' would still have A as its
second parent. Here is the fix that picks the grafted parents instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I know that git-commit is becoming a builtin. At the least, here is
a test that makes sure that the behavior is remains.
-- Hannes
git-commit.sh | 4 ++--
t/t7501-commit.sh | 9 +++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
mode change 100644 => 100755 t/t7501-commit.sh
diff --git a/git-commit.sh b/git-commit.sh
index 7a7a2cb..33e7503 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -529,8 +529,8 @@ then
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
elif test -n "$amend"; then
rloga='commit (amend)'
- PARENTS=$(git cat-file commit HEAD |
- sed -n -e '/^$/q' -e 's/^parent /-p /p')
+ PARENTS=$(git rev-list --parents -1 HEAD |
+ sed -e 's/^[^ ]*//' -e 's/ / -p /g')
fi
current="$(git rev-parse --verify HEAD)"
else
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
old mode 100644
new mode 100755
index b151b51..09c0d98
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -163,4 +163,13 @@ test_expect_success 'partial commit that involves removal (3)' '
'
+test_expect_success '--amend respects grafts' '
+
+ grandparent=$(git rev-parse HEAD~2) &&
+ echo $(git rev-parse HEAD) $grandparent > .git/info/grafts &&
+ git commit --amend -C HEAD &&
+ test "parent $grandparent" = "$(git cat-file commit HEAD | grep "^parent")"
+
+'
+
test_done
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Schindelin @ 2007-09-26 12:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <11908086961933-git-send-email-johannes.sixt@telecom.at>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> This allows a poor-mans-filter-branch of the top-most commit.
>
> Specifically, I had this history:
>
> --o--o--A' <-- amended version of A
> \
> A
> \
> --o--B--M
>
> I now wanted to "amend" M to pull in A' instead of A as its second
> parent. For various reasons I didn't want to redo the merge M again, in
> particular, it already contained the changes that were amended into A'.
> So I figured I would just install a graft that lists B and A' as parents
> of M and then do a simple git commit --amend. Alas, git commit looks at
> the real parents instead of the grafted ones, so the amended M' would
> still have A as its second parent. Here is the fix that picks the
> grafted parents instead.
I do not think that this is a "fix".
I'd really suggest that you fix it up (before the amend!) by installing
the graft, and running git-filter-branch -1 <branch>. (Note: I did not
test this, but it _should_ work. If it does not, please let me know.)
Ciao,
Dscho
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-26 12:42 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F9CA2A.7000107@gmail.com>
On Tue, Sep 25, 2007 at 09:55:38PM -0500, Russ Brown wrote:
> Yes, this is very helpful indeed: thank you for that. /me bookmarks. I
> hadn't actually realised that rebase creates new commits and replaces
> your old ones: I'd thought they just got 'moved' (dunno how I thought it
> worked though!)
It's a necessity, since the commits are named by hash, and the hash
encompasses _all_ of the history. So the same change at a different
location in history will be a different commit.
And that is why rebases can make merging harder. Git can very quickly
compare two commits by hash and say "these are the same commit", or look
at them and say "one side has these changes, the other side has these
other changes, and here is where they meet." Rebasing ruins that, since
the same changes occur in two places with different names.
> I'm just wondering at this point why git lets you checkout remote
> tracking branches if it's something you really shouldn't do. Unless it's
> something you want to be able to do in edge cases to fix screwups maybe?
Junio explained in much more detail, but I use it largely for read-only
access ("oh, let me speed-test my branch against the upstream 'master'";
git-checkout master; test test test; git-checkout mybranch).
> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.
I agree. That sort of information is sprinkled throughout the mailing
list, but it might be nice on a wiki. I have thought of it as a sort of
"git cookbook" where you say "here is a recipe for accomplishing X". The
user manual comes close to this for smaller tasks.
-Peff
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 12:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709261322150.28395@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 26 Sep 2007, Johannes Sixt wrote:
>
>> This allows a poor-mans-filter-branch of the top-most commit.
>>
>> Specifically, I had this history:
>>
>> --o--o--A' <-- amended version of A
>> \
>> A
>> \
>> --o--B--M
>>
>> I now wanted to "amend" M to pull in A' instead of A as its second
>> parent. For various reasons I didn't want to redo the merge M again, in
>> particular, it already contained the changes that were amended into A'.
>> So I figured I would just install a graft that lists B and A' as parents
>> of M and then do a simple git commit --amend. Alas, git commit looks at
>> the real parents instead of the grafted ones, so the amended M' would
>> still have A as its second parent. Here is the fix that picks the
>> grafted parents instead.
>
> I do not think that this is a "fix".
>
> I'd really suggest that you fix it up (before the amend!) by installing
> the graft, and running git-filter-branch -1 <branch>. (Note: I did not
> test this, but it _should_ work. If it does not, please let me know.)
The problem with filter-branch is that it leaves a committer date in M that
is before A', and for this reason is not the right tool for this task. So I
do think that this fix is necessary.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add a --dateformat= option to git-for-each-ref
From: Jeff King @ 2007-09-26 12:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200709261009.18777.andyparkins@gmail.com>
On Wed, Sep 26, 2007 at 10:09:18AM +0100, Andy Parkins wrote:
> For example (I'm in BST, +0100 at present):
>
> $ git-for-each-ref --dateformat=normal --format='%(taggerdate)' refs/tags/v1.5.2
> Sun May 20 00:30:42 2007 -0700
> $ git-for-each-ref --dateformat=relative --format='%(taggerdate)' refs/tags/v1.5.2
> 4 months ago
What if you want a format that contains two dates in different formats?
Something like:
$ git-for-each-ref --format='%(committerdate:relative) %(authordate:normal)'
would be more flexible. Although perhaps that is a bit too unlikely to
be concerned with implementing, giving options to substitutions seems
like a sane way to implement these sorts of things (e.g.,
"%(objectsize:human)", "%(parent:1)", etc).
> + if (!prefixcmp(arg, "--dateformat=")) {
> + arg += 13;
> + if (!prefixcmp(arg,"relative")) {
> + date_mode = DATE_RELATIVE;
> + } else if (!prefixcmp(arg,"short")) {
> + date_mode = DATE_SHORT;
> + } else if (!prefixcmp(arg,"local")) {
> + date_mode = DATE_LOCAL;
> + } else if (!prefixcmp(arg,"iso8601")) {
> + date_mode = DATE_ISO8601;
> + } else if (!prefixcmp(arg,"rfc2822")) {
> + date_mode = DATE_RFC2822;
> + }
> + continue;
> + }
Surely this same code exists elsewhere, and could be easily factored out
into a parse_date_type function.
-Peff
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Schindelin @ 2007-09-26 14:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <46FA5604.101@viscovery.net>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Wed, 26 Sep 2007, Johannes Sixt wrote:
> >
> > > This allows a poor-mans-filter-branch of the top-most commit.
> > >
> > > Specifically, I had this history:
> > >
> > > --o--o--A' <-- amended version of A
> > > \
> > > A
> > > \
> > > --o--B--M
> > >
> > > I now wanted to "amend" M to pull in A' instead of A as its second
> > > parent. For various reasons I didn't want to redo the merge M again,
> > > in particular, it already contained the changes that were amended
> > > into A'. So I figured I would just install a graft that lists B and
> > > A' as parents of M and then do a simple git commit --amend. Alas,
> > > git commit looks at the real parents instead of the grafted ones, so
> > > the amended M' would still have A as its second parent. Here is the
> > > fix that picks the grafted parents instead.
> >
> > I do not think that this is a "fix".
> >
> > I'd really suggest that you fix it up (before the amend!) by
> > installing the graft, and running git-filter-branch -1 <branch>.
> > (Note: I did not test this, but it _should_ work. If it does not,
> > please let me know.)
>
> The problem with filter-branch is that it leaves a committer date in M
> that is before A', and for this reason is not the right tool for this
> task. So I do think that this fix is necessary.
But that's easily fixed with "--env-filter 'export
GIT_COMMITTER_DATE=$(date +%s)'" or something similar.
The reason why I insist on not putting this into --amend is that I think
this is not really an amend, but actively a rewrite of the merge commit.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] git-add--interactive: Allow Ctrl-D to exit
From: Jean-Luc Herren @ 2007-09-26 13:56 UTC (permalink / raw)
To: git; +Cc: gitster
Hitting Ctrl-D (EOF) is a common way to exit shell-like tools.
When in a sub-menu it will still behave as if an empty line had
been entered, carrying out the action on the selected items and
returning to the previous menu.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
git-add--interactive.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 7921cde..f9e9f02 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -213,7 +213,11 @@ sub list_and_choose {
print ">> ";
}
my $line = <STDIN>;
- last if (!$line);
+ if (!$line) {
+ print "\n";
+ $opts->{ON_EOF}->() if $opts->{ON_EOF};
+ last;
+ }
chomp $line;
my $donesomething = 0;
for my $choice (split(/[\s,]+/, $line)) {
@@ -791,6 +795,7 @@ sub main_loop {
SINGLETON => 1,
LIST_FLAT => 4,
HEADER => '*** Commands ***',
+ ON_EOF => \&quit_cmd,
IMMEDIATE => 1 }, @cmd);
if ($it) {
eval {
--
1.5.3
^ permalink raw reply related
* [PATCH 2/2] git-add--interactive: Improve behavior on bogus input
From: Jean-Luc Herren @ 2007-09-26 14:05 UTC (permalink / raw)
To: git; +Cc: gitster
1) Previously, any menu would cause a perl error when entered '0',
which is never a valid option.
2) Entering a bogus choice (like 998 or 4-2) surprisingly caused
the same behavior as if the user had just hit 'enter', which
means to carry out the selected action on the selected items.
Entering such bogus input is now a no-op and the sub-menu
doesn't exit.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
git-add--interactive.perl | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index f9e9f02..be68814 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -219,7 +219,7 @@ sub list_and_choose {
last;
}
chomp $line;
- my $donesomething = 0;
+ last if $line eq '';
for my $choice (split(/[\s,]+/, $line)) {
my $choose = 1;
my ($bottom, $top);
@@ -251,12 +251,11 @@ sub list_and_choose {
next TOPLOOP;
}
for ($i = $bottom-1; $i <= $top-1; $i++) {
- next if (@stuff <= $i);
+ next if (@stuff <= $i || $i < 0);
$chosen[$i] = $choose;
- $donesomething++;
}
}
- last if (!$donesomething || $opts->{IMMEDIATE});
+ last if ($opts->{IMMEDIATE});
}
for ($i = 0; $i < @stuff; $i++) {
if ($chosen[$i]) {
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709261501190.28395@racer.site>
Johannes Schindelin schrieb:
> The reason why I insist on not putting this into --amend is that I think
> this is not really an amend, but actively a rewrite of the merge commit.
You have a point here. I'm convinced. Scrap the patch.
-- Hannes
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Dmitry Potapov @ 2007-09-26 14:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh England, git
In-Reply-To: <7vejgnai1z.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 24, 2007 at 02:07:36PM -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > ... Granted, the
> > branch (and HEAD) does not change for this operation, but that shouldn't
> > matter. It is somewhat in line with the principle of 'least-surprise':
> > if the hook runs for 'git checkout otherbranch', but not 'git checkout
> > otherbranch path.c', this could cause confusion and distress to the
> > user. IMO, it is a 'checkout' so the post-checkout hook should run.
> > Why is that so insane?
>
> Because I find it would be surprising if the following commands
> behave differently:
>
> $ git cat-file blob otherbranch:path.c >path.c
> $ git show otherbranch:path.c >path.c
> $ git diff -R otherbranch path.c | git apply
> $ git checkout otherbranch path.c
Actually, they already act differently even without any hook.
If path.c is a symbol link then 1 and 2 will give a different
result than commands 3 and 4.
On the other hand, while the difference in above commands
understandable (in case 1 and 2, the shell creates path.c; and
in 3 and 4, git creates it), I really dislike the idea of
"checkout is magical." I believe that command 3 and 4 should
always give the same result or Git is broken.
Another reason, why I dislike the post-checkout hook is that it
is prone to abuse like as not so smart user trying to put some
content modification here. Moreover, it appears to be excessive
to me, because if you want to run something after git-checkout,
you can write a simple shell script for that that first runs
git-checkout with the given arguments and then run whatever you
want. I don't see why we should modify Git for that.
Perhaps, it would be better to have a hook on modification,
which is invoked every time when Git wants to try to change
anything in the working directory. The hook could receives on
the input something that looks like 'git-diff --name-status'
output and can do any work on creation files, etc. It is much
more flexible, because you can do additional stuff here like
creating one directory in the path as a symbol link somewhere
else or something like that. But what is much more important
is that everything work _consistently_ and you get the same
results whether you type:
git diff -R otherbranch path.c | git apply
or
git checkout otherbranch path.c
If you start with one "magical interface" then eventually you
will end up with everything being so magical that no one can
make sense of it. Please, stay consistent.
Dmitry Potapov
^ permalink raw reply
* Re: History over-simplification
From: Shawn O. Pearce @ 2007-09-26 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4phi4b9t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I don't really like the patch to revision.c because it winds up
> > showing trivial merges too. What I really want is to have the
> > "--full-history" option include a merge if either of the following
> > is true:
> >
> > a) The resulting path does not match _any_ of the parents. We
> > already handle this case correctly in revision.c and correctly
> > show the "evil" merge.
> >
> > b) The resulting path matches one of the parents but not one of
> > the others. In such a case the merge should still be output if
> > a 3-way read-tree would not have chosen this result by default.
>
> I am not sure (b) is useful in general. Merging two branches
> that fix the same issue but in different ways (think: 'maint'
> and 'master' have different infrastructure and a fix initially
> made on 'master' was backported to 'maint', and then later
> 'maint' needed to be merged to 'master' to carry forward other
> fixes) is a norm, and in such cases taking the version from the
> merged-to branch is almost always what happens.
(b) is useful, even in the case you just described. Try doing the
above backport today. Run `git log maint -- foo.c` and find the
backported commit B. Now try to see if that commit is in master in
foo.c with `git log master -- foo.c`. B won't appear as the merge
of maint into master chose master's revision and maint's history
is pruned away.
Now if the backported change was logically the same but was rewritten
considerably it might take you a while to figure out why a merge
discarded the change B. The merge commit might actually describe
why in its message, but you can't find that particular merge commit
today, even with --full-history. Not without my one-line patch.
Unfortunately my one-line patch causes all of the merges that the
path is involved in to be output. That can be quite a lot of them.
> Also it sounds to me by "if read-tree would not have chosen this
> result by default" you mean this feature would not just need to
> run merge-base but also recursive merge-base synthesis, and also
> recreate the structural merge (aka "rename detection") there as
> well. Even if (b) is useful, it sounds like a very expensive
> option, and the current merge-recursive code is structured in
> such a way to be easily reused for this purpose.
I think you meant here that it is *not* structured in a way to be
easily reused for this purpose. That code relies heavily on the
index to allow it to create that synthetic merge base. Making it
callable from within the revision walker would not be a small change.
But as you say, running merge-recursive here would be a very
expensive option. Which is why I was saying the 3-way read-tree
result as that is cheaper to compute. However the read-tree result
can be different from the merge-recursive result (think renames)
and yet both are still "trivial" resolutions that the user was
never involved in.
Of course other kinds of trivial merges (where changes from the
two branches are in the same file but far enough part it can be
easily merged as a 3-way file merge) appear to the path limiter
as though they were an evil merge, and such merges are output.
So maybe having --full-history output all merges that affected
that path really is the right choice.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] post-checkout hooks and related tests
From: Josh England @ 2007-09-26 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve9y2v39.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-09-25 at 16:17 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > diff --git a/git-checkout.sh b/git-checkout.sh
> > index 17f4392..78355eb 100755
> > --- a/git-checkout.sh
> > +++ b/git-checkout.sh
> > @@ -137,6 +137,13 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
> > git ls-files --error-unmatch -- "$@" >/dev/null || exit
> > git ls-files -- "$@" |
> > git checkout-index -f -u --stdin
> > +
> > + # Run a post-checkout hook -- the HEAD does not change so the
> > + # current HEAD is passed in for both args
> > + if test -x "$GIT_DIR"/hooks/post-checkout; then
>
> It is usually a good idea to view your patch in your MUA before
> sending them out.
>
> You will spot HT vs SP indentation inconsistencies right away.
Dang. It looked ok in emacs. :(
> HEAD did not change but don't you want to differenciate if the
> checkout was from the index or from the HEAD? If not why not?
Hmmmm. It wouldn't hurt to add another arg though I guess in case
someone might use it. I'm just trying to figure out how to word this
nicely in the Documentation.
-JE
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: J. Bruce Fields @ 2007-09-26 18:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1190759824-18896-1-git-send-email-vmiklos@frugalware.org>
On Wed, Sep 26, 2007 at 12:37:04AM +0200, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Tue, Sep 25, 2007 at 04:13:06PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > One exception--the "series of tarballs" thing--I think it's cool that
> > you can just unpack a bunch of tarballs and string them together into a
> > git history. It gives a good sense of how git works, and I don't think
> > it's documented explicitly anywhere. I think that might be kinda fun to
> > write up. But I haven't tried.
>
> something like this?
Neat-o, I'd missed (or forgotten about) import-tars.perl.
But I'd prefer to keep this first explanation of how to initialize and
commit to a new project pretty streamlined, and I don't think this is
really necessary here. So let's save this up until we have enough
material for a separate chapter or section on interacting with other
scm's.
--b.
>
> VMiklos
>
> Documentation/user-manual.txt | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a085ca1..f722932 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -978,6 +978,19 @@ $ git add . # include everything below ./ in the first commit:
> $ git commit
> -------------------------------------------------
>
> +If you already have a series of tarballs (typically previous releases without
> +using a version control system):
> +
> +-------------------------------------------------
> +$ mkdir project
> +$ cd project
> +$ git init
> +$ perl import-tars.perl /path/to/tarballs/*.tar.bz2
> +$ git checkout import-tars
> +-------------------------------------------------
> +
> +You can find `import-tars.perl` in the `contrib/fast-import/` directory.
> +
> [[how-to-make-a-commit]]
> How to make a commit
> --------------------
> --
> 1.5.3.2.80.g077d6f-dirty
>
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: Miklos Vajna @ 2007-09-26 18:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070926181451.GA20976@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
On Wed, Sep 26, 2007 at 02:14:51PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> Neat-o, I'd missed (or forgotten about) import-tars.perl.
>
> But I'd prefer to keep this first explanation of how to initialize and
> commit to a new project pretty streamlined, and I don't think this is
> really necessary here. So let's save this up until we have enough
> material for a separate chapter or section on interacting with other
> scm's.
okay, now it's saved by gmane :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Junio C Hamano @ 2007-09-26 18:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Johannes Sixt, gitster, git
In-Reply-To: <46FA6CD7.1020709@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
>> The reason why I insist on not putting this into --amend is that I
>> think this is not really an amend, but actively a rewrite of the
>> merge commit.
>
> You have a point here. I'm convinced. Scrap the patch.
I am slow today. Since when --amend is not about "a rewrite of
commit"?
^ 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