* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-19 1:16 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi all,
>
> thanks everyone for the nice feedback!
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > It's possible as long as you don't think of the "version number" as a
> > property of the commit, but rather a property that some commits get by
> > virtue of having been at some time the commit that's what would be found
> > on that particular server at that particular time. Even though the history
>
> Right! That is a good point. In fact I don't care about (local) commits,
> but about the pushes to the central server.
>
> > of the *content* is non-linear, the sequence of values stored in
> > refs/heads/master on your central server is linear, local, and easy to
> > enumerate.
>
> That is exactely what I need.
>
> > Of course, when someone does a bunch of development in parallel with other
> > people, does a final merge, and pushes it back to the server, this only
> > increases the version by one, and only the final merge actually has a
>
> As it is now with svn, we have to live with that. The point is that we
> still would see many different commits pushed to the server, so
> git log would show the single items, but the "versioning sequence number"
> is only increased by one. That would be *absolutely*perfect* for me!
>
> > because the intermediate commits don't ever get packages created of them
> > to need to be compared to other packages.
>
> Right!
>
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
There isn't currently anything built in that counts up like that; however,
it shouldn't be too hard to add something, because the reflog gets an
entry at the same times the sequence number would increase. In fact, you
could disable pruning the reflog, and use its length (in lines), except
that would get slow and git doesn't expect you to care about the complete
history there (in fact, you only care about the amount of history past
some point).
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
There isn't a built-in way, but you can find the current hash for a
filename with "git ls-tree -r <branch> <filename>", and find the hash as
of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
looking for the smallest N where they don't match. (And you probably
don't want to be a binary search or the like, because that might miss that
a file was most recently affected by having a change reverted; you'd want
to be sure to report the version that reverted the change, not the version
that introduced the content the later one returned to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Nicolas Pitre @ 2009-10-19 1:15 UTC (permalink / raw)
To: Johan Herland; +Cc: Norbert Preining, git
In-Reply-To: <200910181923.19511.johan@herland.net>
On Sun, 18 Oct 2009, Johan Herland wrote:
> On Sunday 18 October 2009, Norbert Preining wrote:
> > On So, 18 Okt 2009, Johan Herland wrote:
> > > $ git describe
> > > v1.0.4-14-g2414721
> > >
> > > where the "v1.0.4" part is the last tag that the current state is based
> > > on, the "14" part is the number of commit between that tag and the
> > > current
> >
> > So if we have only one tag (initial) then it would count the number
> > of commits?
>
> Yes. You can create the 'initial' tag with
>
> git rev-list HEAD | tail -n1 | xargs git tag initial
>
> and from then on
>
> git describe --tags --match initial | cut -d'-' -f2
Even simpler, without any tag:
git rev-list HEAD | wc -l
That should roughly give the equivalent of the SVN revision number.
Valid only in one specific repository of course.
Nicolas
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git
In-Reply-To: <7vfx9gnwtw.fsf@alter.siamese.dyndns.org>
On So, 18 Okt 2009, Junio C Hamano wrote:
> #2 Do not give such sequential number locally; the central repository is
> the _only_ place that assigns such a number. '?' stands for
> 'unnumbered'
[...]
> Scheme #2 is a way to get some stablility; give the authority of numbering
> to the central repository and commits that haven't hit the central
> repository are left unnumbered. But that is generally not very useful
> for your purpose of giving incrementing version number for building (the
> developers would want to build for testing before finally committing to
> publish the result to the central place).
That problem we have anyway with subversion, too, because as long as you
do not commit your changes nothing will happen on package rebuild.
So that is not a problem here.
Yes, we want server-sided linear numbers and anything *not* pushed to
the server is unnumbered.
And that is also fine, because packages are built only from the server.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
PUDSEY (n.)
The curious-shaped flat wads of dough left on a kitchen table after
someone has been cutting scones out of it.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 0:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910181727130.32515@iabervon.org>
Hi all,
thanks everyone for the nice feedback!
On So, 18 Okt 2009, Daniel Barkalow wrote:
> It's possible as long as you don't think of the "version number" as a
> property of the commit, but rather a property that some commits get by
> virtue of having been at some time the commit that's what would be found
> on that particular server at that particular time. Even though the history
Right! That is a good point. In fact I don't care about (local) commits,
but about the pushes to the central server.
> of the *content* is non-linear, the sequence of values stored in
> refs/heads/master on your central server is linear, local, and easy to
> enumerate.
That is exactely what I need.
> Of course, when someone does a bunch of development in parallel with other
> people, does a final merge, and pushes it back to the server, this only
> increases the version by one, and only the final merge actually has a
As it is now with svn, we have to live with that. The point is that we
still would see many different commits pushed to the server, so
git log would show the single items, but the "versioning sequence number"
is only increased by one. That would be *absolutely*perfect* for me!
> because the intermediate commits don't ever get packages created of them
> to need to be compared to other packages.
Right!
Now my follow-up questions:
- how would one access this "sequence" number on the server
- is there a way to determine at which of this "sequence" numbers a specific
file has been changed last?
Thanks a lot and all the best
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
DULEEK (n.)
Sudden realisation, as you lie in bed waiting for the alarm to go off,
that it should have gone off an hour ago.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* [PATCH] git add -e documentation: rephrase note
From: Miklos Vajna @ 2009-10-19 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <20091014230434.GB29664@coredump.intra.peff.net>
Add a quick overview about what is OK and what is not to cover all
cases.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jeff King <peff@peff.net>
---
On Wed, Oct 14, 2009 at 07:04:34PM -0400, Jeff King <peff@peff.net> wrote:
> Maybe it makes sense instead to do a quick overview of what is OK and
> what is not (like the list above).
Here it is.
Documentation/git-add.txt | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..1ea074c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -86,9 +86,21 @@ OPTIONS
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
-*NOTE*: Obviously, if you change anything else than the first character
-on lines beginning with a space or a minus, the patch will no longer
-apply.
+The intent of this option is to pick and choose lines of the diff to
+apply, or even to munge the lines. So it is safe to:
++
+* remove lines with a "+" (don't stage the addition)
+* munge any lines with a "+" (stage modified contents)
+* add lines with a "+" (stage an addition)
+* convert lines with a " " to "-" (stage removal)
+* convert lines with a "-" to " " (don't stage removal)
++
+It is a bad idea to:
++
+* delete "-" lines
+* delete " " lines
+* add " " or "-" lines
+* munge the contents of " " or "-" lines
-u::
--update::
--
1.6.5
^ permalink raw reply related
* [PATCH] Document git push -q
From: Miklos Vajna @ 2009-10-18 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Pipping, Jeff King, git
In-Reply-To: <4ADB4AE8.5070007@hartwork.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Oct 18, 2009 at 07:05:44PM +0200, Sebastian Pipping <webmaster@hartwork.org> wrote:
> If I'm not mistaken --quiet is not documented in the git-push man page.
> This includes release 1.6.5.1.
Here is a patch to document it.
Documentation/git-push.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..beb3422 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -138,6 +138,12 @@ useful if you write an alias or script around 'git-push'.
--verbose::
Run verbosely.
+-q::
+--quiet::
+ Some transports produce output even without `--verbose` turned
+ on. This provides a way to tell them to be more quiet (whereas
+ simply redirecting might lose error messages).
+
include::urls-remotes.txt[]
OUTPUT
--
1.6.5
^ permalink raw reply related
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Vietor Liu, Björn Gustavsson; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Vietor Liu <vietor@vxwo.org>
> Subject: [PATCH v4] git-gui: adjust the minimum height of diff pane for
> Date: Fri, 16 Oct 2009 17:41:26 +0800
> Message-Id: <1255686086-3949-1-git-send-email-vietor@vxwo.org>
>
> When the main window is maximized, if the screen height is shorter (e.g.
> Netbook screen 1024x600), both the partial commit pane and the status bar
> are hidden.
I never apply patches to git-gui and gitk myself, but expect to be fed
them via respective area experts.
> From: Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] bash: complete more options for 'git rebase'
> Date: Sat, 17 Oct 2009 11:33:38 +0200
> Message-ID: <4AD98F72.1060901@gmail.com>
>
> Complete all long options for 'git rebase' except --no-verify
> (probably used very seldom) and the long options corresponding
> to -v, -q, and -f.
Likewise; I was expecting Shawn to Ack/Nak this one.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: "Tom G. Christensen" <tgc@statsbiblioteket.dk>
> Subject: [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
> Date: Tue, 13 Oct 2009 13:14:31 +0200
> Message-ID: <1255432471-14168-1-git-send-email-tgc@statsbiblioteket.dk>
>
> This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
> by installing the modules into the perl libdir and not $(prefix)/lib.
> It will default to sitelib but will allow the user to choose by setting
> the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.
I still have this in my inbox, but I tend to wait for Acks to patches that
touch perl/ area before acting on them, which hasn't happened.
P.S. Originally I somehow mistook this from tchrist (aka thoth) and
blindly applied, but then realized it is a different Tom with slightly
different family name and recategorized the patch to go through the usual
review cycle.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git, Nanako Shiraishi
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Geoffrey Thomas <geofft@mit.edu>
> Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
> Date: Sat, 12 Sep 2009 19:49:48 -0400
> Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>
>
> Since order files tend to be useful for all operations in the
> project/repository, add a default location for the order file, so that
> you don't have to specify -O<orderfile> on every diff or similar
> operation.
Except that "$GIT_DIR/info/order" is a bit too generic a name ("eh,
'order'? Order of what?"), I do not think this will hurt, as no existing
repositories would have such a file that would cause any behaviour change
to existing users. The reason I did not queue it was because there wasn't
any discussion on it (not even the filename being too generic) which was
an indication that not many people are interested in such a feature.
That of course can be remedied by interested people speaking out.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Carlos R. Mafra, Björn Gustavsson, René Scharfe
Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: "Carlos R. Mafra" <crmafra@aei.mpg.de>
> Subject: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
> Date: Sun, 11 Oct 2009 15:32:19 +0200
>
> 'make clean' should remove the object files from block-sha1/
> instead of the non-existent mozilla-sha1/ directory.
This was lost in the noise, and it is an obviously correct patch.
Thanks for a reminder.
> From: Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
> Date: Thu, 15 Oct 2009 18:39:05 +0200
> Message-ID: <4AD75029.1010109@gmail.com>
>
> Correct the usage text to make it clear that --tags cannot
> be combined with --all or --mirror.
Ditto.
> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> Subject: [PATCH] describe: load refnames before calling describe()
> Date: Sat, 17 Oct 2009 18:30:48 +0200
> Message-ID: <4AD9F138.3080405@lsrfire.ath.cx>
>
> Get rid of the static variable that was used to prevent loading all
> the refnames multiple times by moving that code out of describe(),
> simply making sure it is only run once that way.
Ditto.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:31 UTC (permalink / raw)
To: Rolf Bjarne Kvinge, Per Strandh; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
> Subject: git rev-list --pretty=raw strips empty lines
> Date: Tue, 06 Oct 2009 14:33:37 +0200
> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>
> It seems like the --pretty=raw format strips off empty newlines from
> the beginning of log messages, while I'd expect the raw format to
> not do any transformations (just as the documentation says: "The
> 'raw' format shows the entire commit exactly as stored in the commit
> object").
>
> The below changes works for me, not sure if I'm right about this
> though (my first time here ;-)
I do not recall seeing this one; most likely it was lost in the noise,
especially because it did not look like a patch submission, without having
anything resembling a commit log message.
I think the change itself is an uncontroversial one, even though this
really changes the behaviour.
> From: Per Strandh <Per.Strandh@q-matic.se>
> Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
> Date: Tue, 13 Oct 2009 22:09:12 +0200
> Message-ID: <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
>
> git-p4 clone (and sync) did not work if the specified depot path contained spaces.
> Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
I do recall ignoring this one because (1) I never use git-p4 myself and
always rely on Acks from people who have been involved in it, and (2) the
message was mangled (perhaps it had two or three copies of patches as
attachments).
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:31 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Jeff King <peff@peff.net>
> Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
> Date: Wed, 23 Sep 2009 15:14:29 -0400
> Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>
>
> Bug. The script does a chdir() and then looks at the cvspsfile later. I
> think "-A" would have the same problem. Here is a totally untested patch
> to address the issue. Johannes, will this is_absolute_path actually work
> on Windows? I think The Right Way would be to use
> File::Spec::file_name_is_absolute, but I haven't checked whether that is
> part of core perl and if so, which version it appeared in.
My understanding of this is that it is a typical "how about this" that is
still waiting for a follow-up discussion that will result in an eventual
solution.
> From: Junio C Hamano <gitster@pobox.com>
> Subject: Re: Q: supplying large sets of path to git commands
> Date: Fri, 16 Oct 2009 15:08:07 -0700
> Message-ID: <7vtyxzrnzs.fsf@alter.siamese.dyndns.org>
>
> Here is how one might implement it for diff/log family of commands that
> use "setup_revisions()".
>
> I didn't test it (of course) beyond running
>
> ./git diff --name-only HEAD | ./git diff --stdin-paths --stat -p
Ditto.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:31 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: gitster, git, bgustavsson, tgc, geofft, hvoigt, peff, RKvinge,
crmafra, Per.Strandh, vietor, rene.scharfe
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
Thanks; very appreciated, and I wish there were more like you to help us
keep track things.
Will comment on individual patches separately.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:31 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Nanako Shiraishi
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Heiko Voigt <hvoigt@hvoigt.net>
> Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> Date: Wed, 23 Sep 2009 20:30:28 +0200
> Message-ID: <20090923183023.GA85456@book.hvoigt.net>
>
> This is useful if you are using the testsuite with local changes that
> include activated default hooks suitable for your teams installation.
This may be useful when Heiko or somebody actually has changes that needs
this fix, but otherwise was an unnecessary code churn during pre-release
code freeze. I am reasonably sure that Heiko will include it in a series
that requires this one.
In other words, I am not against it per-se, but I would prefer to see
patches that actually depends on this change at the same time. Otherwise
this "is supposed to be no-op, and promises it will help in the future",
and needs extra mental effort to validate the latter claim.
^ permalink raw reply
* Re: git push should automatically push to remote tracking branch
From: Tomas Carnecky @ 2009-10-18 23:11 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910181320j15a273e8vc510801c890b93a9@mail.gmail.com>
On Oct 18, 2009, at 10:20 PM, Mohit Aron wrote:
> Hello,
>
> I've been using git for around a year now and I'm continuing to find
> the 'git push' API rather cumbersome. My workflow is as follows. I
> typically have a local branch track a remote branch and want to pull
> and push changes back and forth. The names of the local and remote
> branches are different. Even so, while 'git pull' is enough to pull
> changes, 'git push' is not. Instead, the pull requires a full refspec
> to be specified which gets real cumbersome and error prone.
>
> Say my local branch name is foo and it is tracking a remote release
> branch of a product. Say the remote's name is origin and corresponding
> branch there is 6.1. 'git pull' nicely fetches and merges changes
> submitted by others in the remote branch to my branch foo. However, to
> do a push, I need to call:
>
> git push origin HEAD:6.1
>
> Since my local branch has been setup to track the remote branch, I
> shouldn't have to specify all this in the 'git push' command. It'll be
> great if 'git push' were to support a variant that automatically
> allows pushing to the remotely tracked branch. This is the typical
> workflow with other version control systems too.
>
> If anyone knows a simpler alternative I can use in Git, please let me
> know. Otherwise, it'll be great if such a feature could be added to
> Git in the future.
$ git config push.default tracking
tom
^ permalink raw reply
* Re: [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Junio C Hamano @ 2009-10-18 22:50 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: B.Steinbrink, Junio C Hamano, git, Johannes Schindelin,
Jay Soffian
In-Reply-To: <20091019052043.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>>> In the subject you used 'git checkout -b frotz origin/frotz'. Did you
>>> forget to say '-t'?
>>
>> Hm, the DWIMmery only triggers when opts.track is
>> BRANCH_TRACK_UNSPECIFIED, i.e. -t was not used. And it doesn't change
>> opts.track when it DWIMs, so it respects branch.autosetupmerge, which
>> would be overriden by -t. So it seems correct that -t is not in there.
>
> I see.
>
> A user who always wants tracking can set the config option and use
> the new "git checkout frotz" shortcut, but a user who usually
> doesn't want tracking doesn't have the config option and when he
> wants tracking only for this new branch he can explicitly say "git
> checkout -t origin/frotz", right?
Correct.
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Junio C Hamano @ 2009-10-18 22:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <20091018210222.GA5371@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> The one which guesses local branch name from a remote reference.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Maybe like this?
>
> BTW, can parse-options take care of the " (default)" addition?
>
> builtin-checkout.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 6ec9b83..22b023b 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -632,8 +632,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> OPT_STRING(0, "conflict", &conflict_style, "style",
> "conflict style (merge or diff3)"),
> OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
> - OPT_SET_INT(0, "nodwim", &dwim_new_local_branch,
> - "do not dwim local branch creation", 0),
> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
> + "Guess local branch from remote reference (default)", 0),
Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
with --no-dwim?
> OPT_END(),
> };
> int has_dash_dash;
> --
> 1.6.5.1.50.g84e6e
^ permalink raw reply
* Re: [PATCH v3 1/5] Refactor pretty_print_commit arguments into a struct
From: Junio C Hamano @ 2009-10-18 22:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <200910182051.20461.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> The existing calls to format_commit_message() often take DATE_NORMAL to
>> its "enum date_mode dmode" argument, and you replaced it with a pointer to
>> a struct. DATE_NORMAL happens to be "0" and the compiler does not catch
>> calls you forgot to convert in this patch.
>
> Hmph, that's embarrassing. Apparently I was way too focused on
> pretty_print_commit...
This is nothing to be embarrassed about. I did not notice it when I
queued the series either, and I noticed it only when I tried to look at
interactions with js/diff-verbose-submodule topic(the other series does
not hardcode the style to be DATE_NORMAL).
One solution to help the compiler catch this kind of semantic crash upon
merging or applying code based on the old format_commit_message() would
have been to change its function signature (or even the name), so that it
would not go unnoticed that DATE_NORMAL that happens to be "0" is silently
interpreted as (void *)0 == NULL.
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Junio C Hamano @ 2009-10-18 22:47 UTC (permalink / raw)
To: Norbert Preining; +Cc: Johan Herland, git
In-Reply-To: <20091018152054.GA3956@gamma.logic.tuwien.ac.at>
Norbert Preining <preining@logic.at> writes:
> On So, 18 Okt 2009, Johan Herland wrote:
>> A global, increasing version number ala SVN is fundamentally impossible in
>> any distributed version control system (like Git).
>
> Yes, agreed.
>
> The point is that I do not actually need the "distributed" part of git.
> I want one central repository and all collaborators commit to that.
> Yes, that is subversion, I know.
>
> We have no branches, no tags, nothing of that. Only trunk.
No, it is not subversion at all. Don't say "I know" until you really
know. Anybody who thinks that is not distributed does not understand
distributedness of git.
Distributedness does _not_ come from not having a central shared
repository, nor not using more than one branch.
Distrubutedness comes the moment any and all of your people can make their
commits _locally_. And the fundamental lack of "increasing global version
number" is one implication of the distributedness.
Suppose you and Alice collaborate that way. You make the initial commit,
that is pushed to the central shared repository, and alice clones.
norb$ git commit -m 'first one'
norb$ git push
alice$ git clone $central
Now Norb and Alice share that the 'first one' is the current and only
commit at the tip of their history. The central repository also shares
that notion. You work and produce a few commits.
norb$ edit; git commit -a -m 'second norb'
norb$ edit; git commit -a -m 'third norb'
norb$ edit; git commit -a -m 'fourth norb'
while Alice does the same.
alice$ edit; git commit -a -m 'second alice'
alice$ edit; git commit -a -m 'third alice'
You happened to push first:
norb$ git push
You and the central repository shares the view of the history in which
the mapping between "revision sequence number" and commits looks like:
1. first one
2. second norb
3. third norb
4. fourth norb
Imagine what view of the history Alice has at this point and think for a
while. Recall Alice hasn't pulled from the central repository since she
cloned. There are two possible things you may want to do.
#1 Some sequential number is given but that is useless as global
identifier.
1. first one
2. second alice
3. third alice
#2 Do not give such sequential number locally; the central repository is
the _only_ place that assigns such a number. '?' stands for
'unnumbered'
1. first one
?. second alice
?. third alice
Then Alice fetches from the central and integrates her history with it.
She can do one of two things. "pull" to create a non-linear history by
merging, or "pull --rebase" to keep the history linear.
Since you are imitating subversion, you may choose the latter route to
rebase, and now the linearlized history would become:
1. first one
2. second norb
3. third norb
4. fourth norb
?. second alice
?. third alice
Alice's two commits may stay unnumbered (if you chose #2---no local
versions), or changes from 2/3 to 5/6 (if you chose #1).
If you instead use merges, then there won't be 'sequence' number you can
usefully compare anymore.
1 first one
/|
second alice 2 2 second norb
| |
| 3 third norb
| |
third alice 3 4 fourth norb
|/
fourth alice 5
Scheme #1 inherently cannot give you stable and unique numbers in a
distributed environment where you can commit locally without talking to
the central "number naming authority". By rebasing, you can keep the
long-term numbering unique (by renaming some new ones), but rebase has its
own downsides besides the name of the commit.
Scheme #2 is a way to get some stablility; give the authority of numbering
to the central repository and commits that haven't hit the central
repository are left unnumbered. But that is generally not very useful
for your purpose of giving incrementing version number for building (the
developers would want to build for testing before finally committing to
publish the result to the central place).
Running describe using one tag on the 'initial' would give you a rough
equivalent of #1 (i.e. you get tentative numbers on the local commits),
both in the case you rebase (i.e. your numbers change) and you merge
(i.e. you can have more than one "second" commits and numbers are not
unique), which would be the best compromise you can get.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-18 22:47 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Junio C Hamano, Julian Phillips, Daniel Barkalow, James Pickens,
Jeff King, Nicolas Pitre, Jay Soffian, git
In-Reply-To: <20091017194153.GA30003@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:
>> The "save" part of the work-save-then-merge sequence should be made very
>> visible to help people get used to the "not up, but work-save-then-merge"
>> mental model. I do not think it would help people in the long run to make
>> the "save" step less visible by wrapping the sequence into an unreliable
>> "up" script, especially because the script would sometimes work but other
>> times *has to* force users to know that what is happening behind the scene
>> is work-save-then-merge in order to resolve and recover from conflicts
>> anyway.
>
> Hm, which cases would that be? I basically see three cases:
>
> 1) No uncommitted changes => No problem
> 2) Uncommitted changes merge cleanly => No problem
> 3) Uncommitted changes causes conflicts =>
> - User can resolve
> - User can start over (git update --retry)
> - User can give up (git update --abort)
By "--abort", if you meant to discard the local change, that is only
suitable for people who would say "what I was doing was minor anyway, and
I'll redo them based on the updated upstream", and may not be so useful, I
think. The user may want to pretend that he did not even start "update"
(i.e. not pulled while he was still working on something) at this point,
and if you meant by "give up" (aka --abort) to "reset --hard @{1} &&
unstash", I think it makes quite a lot of sense. Then the user has an
option to fork a topic at that point:
git update --abort
git checkout -b topic
work on more with committing
git checkout master
git update
But then this starts to look more like an enhanced failure recovery mode
for "git pull" command.
In addition, I think that you would internally implement the "save" step
with "stash" (which would be a sane thing to do), but then you would need
to worry about the case where the user was in the middle of a merge (or
"revert", "cherry-pick", "checkout -m") that did not complete. "git pull"
fails upfront, says why and tells users what to do. "git update" should
do the same.
> I do see problems with a "stash around merge" thing ("stash" around
> rebase seems easier, as that could just create a commit and reset later,
> but I'm not exactly sure that such smartness is a good idea). As soon as
> the merge has conflicts, you need to know that you have to unstash after
> committing the merge, but what I have in mind is fast-forward only (or
> possibly reset, when upstream was rewritten). Primarily for users that
> don't commit at all, but just look at things [*1*].
Ok. If you have a clean way to guarantee that "update" users won't
commit, I think the above would sort of make sense and my earlier worries
about (1) a user who wish he did not fetch and (2) a user who was doing
something more complex and had conflicts already would go away.
If the sole target audience is "minor changes only, never committing"
people, then I would even rescind my earlier suggestion on --abort; it
should mean "remove the minor changes and get pristine copy of the
upstream---the user will redo the minor changes to adjust to the updated
upstream from scratch", to keep the end user experience simpler and
clearer.
I am undecided if it is a good thing to divide the userbase into two
classes, "update" people and "work-commit-fetch-merge-resolve" people.
> [*1*] One could also say: Users that don't give a damn about git, but
> just need it to get the code and maybe have some minor, uncommitted
> modifications on top. I'm _not_ thinking about users that actually
> commit and do stuff. Those should use merge/rebase/pull, and get a
> complaint from "git update" if the update is not a fast-forward one,
> telling them what to use instead.
^ permalink raw reply
* Re: [PATCH 0/3] Generalized "string function" syntax
From: Junio C Hamano @ 2009-10-18 22:47 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4ADAD0D2.504@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Which other text functions are we going to add which would break this
> model? The only thing I can think of right now is nesting such
> functions themselves, e.g. when indenting a list in an indented
> sub-paragraph in an indented paragraph. Useful?
I was more worried about painting ourselves now in a corner we cannot get
out of easily later. Even if my answer to question "what are we going to
add" may be "nothing I can think of right now", it does not make me happy.
Something off the top of my head are combinations like these.
%[toupper()%cD%] => 'SUN, 18 OCT 2009 12:34:56 -0700'
%[substr(7,3)%[toupper()%cD%]] => 'OCT'
%[sanitize()%s%] === %f (i.e. format-patch filename)
%[sanitize()%[substr(0,7)%[toupper()%aN%]%]%s] (with upcased author name)
By the way, I think that date formatting can be helped by introducing a
strftime() function that takes %ct/%at as input, e.g. %aD would become
%[strftime(%a, %d %b %Y %H:%M:%S %z)%at]
and we do not have to worry about keep adding random %[ac]X formats and
running out of X. Right now we use d/D/r/i and there were talks of adding
a shortened 8601 format without time or something we did not implement.
Also, if we had this %[func() any string%] mechanism, we probably wouldn't
have had to add distinction between n/N and e/E after %a and %c.
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-18 21:43 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091018144158.GA9789@gandalf.dynalias.org>
On Sun, 18 Oct 2009, Norbert Preining wrote:
> Dear all,
>
> (please Cc)
>
> I am managing some of my projects with git and I am quite happy about it.
>
> There is another project I am working that is quite big, the subversion
> checkout is about 14Gb. Doing svn up is a pain, it has to open tens of
> thousands of files and directories traversing the whole tree, trashing
> the fs cache and taking ages.
>
> My idea was to move to git, from what I read it should be more capable
> in handling these type of projects.
>
> Now, there is one show-stopper I see. From our repository we create a
> set of "packages", and the maximum of the "last-changed" revisions of
> the contained files determine the "version" of the package. This
> guarantees that any change in a file will increase the revision number
> of the package (some tricks for removals have to be done). This is necessary
> since we are distributing the packages from servers and the version number
> pf a package determines whether it should be upgraded (well known concept).
>
> Now my question, is there any way to set up something similar with git?
>
> My idea is that git - like subversion - could (if asked to) count each
> commit (global to the repository, irrelevant of the branch) and give it
> a version number. Since we all will use a bare repository on a server
> and pull/push from/to there, I think that something similar could be possible.
It's possible as long as you don't think of the "version number" as a
property of the commit, but rather a property that some commits get by
virtue of having been at some time the commit that's what would be found
on that particular server at that particular time. Even though the history
of the *content* is non-linear, the sequence of values stored in
refs/heads/master on your central server is linear, local, and easy to
enumerate.
Of course, when someone does a bunch of development in parallel with other
people, does a final merge, and pushes it back to the server, this only
increases the version by one, and only the final merge actually has a
version number at all. For your application, this shouldn't be a problem,
because the intermediate commits don't ever get packages created of them
to need to be compared to other packages.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Alex Riesen @ 2009-10-18 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7v7huspjg0.fsf@alter.siamese.dyndns.org>
The one which guesses local branch name from a remote reference.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Sun, Oct 18, 2009 21:53:51 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > On Sun, Oct 18, 2009 at 10:01, Junio C Hamano <gitster@pobox.com> wrote:
> >> + OPT_SET_INT(0, "nodwim", &dwim_new_local_branch,
> >> + "do not dwim local branch creation", 0),
> >
> > Isn't there a special negation support for --no-something in parse-options?
>
> There probably is, but this is a whetherbaloon patch without documentation
> and pretty much Porcelain only, so I took the lazy route.
>
> Helping hands in polishing it up is very welcome.
Maybe like this?
BTW, can parse-options take care of the " (default)" addition?
builtin-checkout.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 6ec9b83..22b023b 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -632,8 +632,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
- OPT_SET_INT(0, "nodwim", &dwim_new_local_branch,
- "do not dwim local branch creation", 0),
+ OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
+ "Guess local branch from remote reference (default)", 0),
OPT_END(),
};
int has_dash_dash;
--
1.6.5.1.50.g84e6e
^ permalink raw reply related
* Unapplied patches reminder
From: Nanako Shiraishi @ 2009-10-18 20:20 UTC (permalink / raw)
To: gitster
Cc: git, bgustavsson, tgc, geofft, hvoigt, peff, RKvinge, crmafra,
Per.Strandh, vietor, bgustavsson, rene.scharfe
Junio, I saw these patches and thought what they try to do were
sensible, but I don't them in your tree. I didn't see much discussion
on most of them, either.
Because I don't read C very well, I may have listed some patches
here that you may have discarded because the code was no good, and
if so I apologize for wasting your time, but I thought at least
some of them should be salvaged.
Here is the list.
From: Geoffrey Thomas <geofft@mit.edu>
Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
Date: Sat, 12 Sep 2009 19:49:48 -0400
Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>
Since order files tend to be useful for all operations in the
project/repository, add a default location for the order file, so that
you don't have to specify -O<orderfile> on every diff or similar
operation.
From: Heiko Voigt <hvoigt@hvoigt.net>
Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
Date: Wed, 23 Sep 2009 20:30:28 +0200
Message-ID: <20090923183023.GA85456@book.hvoigt.net>
This is useful if you are using the testsuite with local changes that
include activated default hooks suitable for your teams installation.
From: Jeff King <peff@peff.net>
Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
Date: Wed, 23 Sep 2009 15:14:29 -0400
Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>
Bug. The script does a chdir() and then looks at the cvspsfile later. I
think "-A" would have the same problem. Here is a totally untested patch
to address the issue. Johannes, will this is_absolute_path actually work
on Windows? I think The Right Way would be to use
File::Spec::file_name_is_absolute, but I haven't checked whether that is
part of core perl and if so, which version it appeared in.
From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
Subject: git rev-list --pretty=raw strips empty lines
Date: Tue, 06 Oct 2009 14:33:37 +0200
Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
It seems like the --pretty=raw format strips off empty newlines from the beginning of log messages, while I'd expect the raw format to not do any transformations (just as the documentation says: "The 'raw' format shows the entire commit exactly as stored in the commit object").
The below changes works for me, not sure if I'm right about this though (my first time here ;-)
From: "Carlos R. Mafra" <crmafra@aei.mpg.de>
Subject: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
Date: Sun, 11 Oct 2009 15:32:19 +0200
'make clean' should remove the object files from block-sha1/
instead of the non-existent mozilla-sha1/ directory.
From: Per Strandh <Per.Strandh@q-matic.se>
Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
Date: Tue, 13 Oct 2009 22:09:12 +0200
Message-ID: <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
From: "Tom G. Christensen" <tgc@statsbiblioteket.dk>
Subject: [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
Date: Tue, 13 Oct 2009 13:14:31 +0200
Message-ID: <1255432471-14168-1-git-send-email-tgc@statsbiblioteket.dk>
This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
by installing the modules into the perl libdir and not $(prefix)/lib.
It will default to sitelib but will allow the user to choose by setting
the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.
From: Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
Date: Thu, 15 Oct 2009 18:39:05 +0200
Message-ID: <4AD75029.1010109@gmail.com>
Correct the usage text to make it clear that --tags cannot
be combined with --all or --mirror.
From: Vietor Liu <vietor@vxwo.org>
Subject: [PATCH v4] git-gui: adjust the minimum height of diff pane for
Date: Fri, 16 Oct 2009 17:41:26 +0800
Message-Id: <1255686086-3949-1-git-send-email-vietor@vxwo.org>
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden.
From: Junio C Hamano <gitster@pobox.com>
Subject: Re: Q: supplying large sets of path to git commands
Date: Fri, 16 Oct 2009 15:08:07 -0700
Message-ID: <7vtyxzrnzs.fsf@alter.siamese.dyndns.org>
Here is how one might implement it for diff/log family of commands that
use "setup_revisions()".
I didn't test it (of course) beyond running
./git diff --name-only HEAD | ./git diff --stdin-paths --stat -p
From: Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] bash: complete more options for 'git rebase'
Date: Sat, 17 Oct 2009 11:33:38 +0200
Message-ID: <4AD98F72.1060901@gmail.com>
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Subject: [PATCH] describe: load refnames before calling describe()
Date: Sat, 17 Oct 2009 18:30:48 +0200
Message-ID: <4AD9F138.3080405@lsrfire.ath.cx>
Get rid of the static variable that was used to prevent loading all
the refnames multiple times by moving that code out of describe(),
simply making sure it is only run once that way.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Nanako Shiraishi @ 2009-10-18 20:20 UTC (permalink / raw)
To: B.Steinbrink; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <20091018120053.GA11391@atjola.homenet>
Quoting Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2009.10.18 19:34:48 +0900, Nanako Shiraishi wrote:
>> Quoting Junio C Hamano <gitster@pobox.com>
>>
>> > When 'frotz' is not a valid object name nor a tracked filename,
>> > we used to complain and failed this command. When there is only
>> > one remote that has 'frotz' as one of its tracking branches, we can
>> > DWIM it as a request to create a local branch 'frotz' forking from
>> > the matching remote tracking branch.
>>
>> In the subject you used 'git checkout -b frotz origin/frotz'. Did you
>> forget to say '-t'?
>
> Hm, the DWIMmery only triggers when opts.track is
> BRANCH_TRACK_UNSPECIFIED, i.e. -t was not used. And it doesn't change
> opts.track when it DWIMs, so it respects branch.autosetupmerge, which
> would be overriden by -t. So it seems correct that -t is not in there.
I see.
A user who always wants tracking can set the config option and use
the new "git checkout frotz" shortcut, but a user who usually
doesn't want tracking doesn't have the config option and when he
wants tracking only for this new branch he can explicitly say "git
checkout -t origin/frotz", right?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox