* 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
* git push should automatically push to remote tracking branch
From: Mohit Aron @ 2009-10-18 20:20 UTC (permalink / raw)
To: git
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.
- Mohit
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Junio C Hamano @ 2009-10-18 19:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <81b0412b0910180540u7030c22br7efcaf7f51df771d@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH v3 1/5] Refactor pretty_print_commit arguments into a struct
From: Thomas Rast @ 2009-10-18 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <7vljja7xy8.fsf@alter.siamese.dyndns.org>
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...
I can devise a test that would have detected this. Should I include
it in the reroll, or is that something we do not guard against?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: alexandrul @ 2009-10-18 18:16 UTC (permalink / raw)
To: Johan Herland; +Cc: Norbert Preining, git
In-Reply-To: <200910181923.19511.johan@herland.net>
Johan Herland wrote:
> 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
>
> will give you the increasing "revision" number you're looking for. Just be
> aware that if you have two parallel branches with the same number of
> commits, they will give you the same number. I.e. this only works for a
> single, stable (i.e. no history rewrites), branch of development.
So if you concatenate the branch name with the "revision" number you would have
pretty unique tags repo-wide, if you won't rename your branches.
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Johan Herland @ 2009-10-18 17:23 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091018152054.GA3956@gamma.logic.tuwien.ac.at>
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
will give you the increasing "revision" number you're looking for. Just be
aware that if you have two parallel branches with the same number of
commits, they will give you the same number. I.e. this only works for a
single, stable (i.e. no history rewrites), branch of development.
Hope this helps,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Sebastian Pipping @ 2009-10-18 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wfi1fya.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * "git push" can be told to be --quiet.
If I'm not mistaken --quiet is not documented in the git-push man page.
This includes release 1.6.5.1.
Sebastian
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: alexandrul @ 2009-10-18 16:35 UTC (permalink / raw)
To: demerphq; +Cc: Norbert Preining, git
In-Reply-To: <9b18b3110910180916s2a2ac751i7520e64294037817@mail.gmail.com>
demerphq wrote:
> Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.
>
> If i then make a trivial comment fix to A and then merge and push we
> end up with:
>
> A-B-C-D-E-G
> \ /
> F------+
>
> If i understand you right you will set F to 6 and G to 7. Thus youll
> end up with the problem that F is a descendent of A yet has a higher
> "version number" than E. You can repeat this process for ever.
>
> If this suits your needs then great.
Just like subversion :D
It helps by ordering commits by time, not by parents, and I don't need
repo access to figure it out that F is the latest bug/feature/fix.
Think about 2 sql servers, each has different versions of the same
stored procedure. Which one is newer, given that you don't have
the git repository on the production servers? I can't make any decision
on SHA1 only, and if they belong to the same branch ("prod")
I'm so out of luck. At the moment I'm saving SHA1, refs, author date,
comitter date and last subject. But it's easier for me to compare
revision numbers than dates. And don't forget that updating decisions
may be taken by people that have nothing to do with development.
Have a nice day,
A.
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: demerphq @ 2009-10-18 16:16 UTC (permalink / raw)
To: Norbert Preining; +Cc: alexandrul, git
In-Reply-To: <20091018154528.GA5688@gamma.logic.tuwien.ac.at>
2009/10/18 Norbert Preining <preining@logic.at>:
> On So, 18 Okt 2009, demerphq wrote:
>> > Being a DVCS, this kind of versioning can only be trusted on a single repo,
>> > but if you set it on the "main" repo, it should work.
>> >
>> > The only drawback could be the ever growing number of tags,
>> > I don't know how it will work with thousands of tags or more.
>>
>> I think the other drawback is that the number would essentially be
>> meaningless and more or less would just be a substitute sha1.
>
> Well, it would be increasing for that repository. And if we always
> update our packages from that repository the packages will be guaranteed
> to have increasing version number, too.
>
> That is the *only* thing I care about. The numbers don't need to have
> a meaning, nothing else but that in our workflow we guarantee
> that at the end each package progresses in version numbers.
>
>> Consider when a remote adds commits and then merges and pushes. What
>> number should those commits have?
>
> When using a central repository to which he pushes within that central
> repository it would give a specific number.
Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.
If i then make a trivial comment fix to A and then merge and push we
end up with:
A-B-C-D-E-G
\ /
F------+
If i understand you right you will set F to 6 and G to 7. Thus youll
end up with the problem that F is a descendent of A yet has a higher
"version number" than E. You can repeat this process for ever.
If this suits your needs then great.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-18 15:45 UTC (permalink / raw)
To: demerphq; +Cc: alexandrul, git
In-Reply-To: <9b18b3110910180837h18e15f74g74626847b6ce4da3@mail.gmail.com>
On So, 18 Okt 2009, demerphq wrote:
> > Being a DVCS, this kind of versioning can only be trusted on a single repo,
> > but if you set it on the "main" repo, it should work.
> >
> > The only drawback could be the ever growing number of tags,
> > I don't know how it will work with thousands of tags or more.
>
> I think the other drawback is that the number would essentially be
> meaningless and more or less would just be a substitute sha1.
Well, it would be increasing for that repository. And if we always
update our packages from that repository the packages will be guaranteed
to have increasing version number, too.
That is the *only* thing I care about. The numbers don't need to have
a meaning, nothing else but that in our workflow we guarantee
that at the end each package progresses in version numbers.
> Consider when a remote adds commits and then merges and pushes. What
> number should those commits have?
When using a central repository to which he pushes within that central
repository it would give a specific number.
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
-------------------------------------------------------------------------------
WIMBLEDON (n.)
That last drop which, no matter how much you shake it, always goes
down your trouser leg.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: demerphq @ 2009-10-18 15:37 UTC (permalink / raw)
To: alexandrul; +Cc: Norbert Preining, git
In-Reply-To: <4ADB3452.6030508@gmail.com>
2009/10/18 alexandrul <alexandrul.ct@gmail.com>:
> Norbert Preining wrote:
>> 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.
>
> I was thinking to set a post-commit hook that reads the current version
> from a file, increment and save it, and also set a tag with that value.
>
> Being a DVCS, this kind of versioning can only be trusted on a single repo,
> but if you set it on the "main" repo, it should work.
>
> The only drawback could be the ever growing number of tags,
> I don't know how it will work with thousands of tags or more.
I think the other drawback is that the number would essentially be
meaningless and more or less would just be a substitute sha1.
Consider when a remote adds commits and then merges and pushes. What
number should those commits have?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Jon Smirl @ 2009-10-18 15:37 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091018144158.GA9789@gandalf.dynalias.org>
On Sun, Oct 18, 2009 at 10:41 AM, Norbert Preining <preining@logic.at> 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.
There is a large LKML thread discussing this....
http://lwn.net/Articles/355923/
>
> So, before I delve into more gitty-nitty conversion, let me know if
> there is any chance for that, or we should stay with subversion.
>
> Thanks a lot and all the best
>
> Norbert
>
> PS: for those interested, it is TeX Live: www.tug.org/texlive
>
> -------------------------------------------------------------------------------
> 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
> -------------------------------------------------------------------------------
> YONKERS (n.)
> (Rare.) The combined thrill of pain and shame when being caught in
> public plucking your nostril-hairs and stuffing them into your
> side-pocket.
> --- Douglas Adams, The Meaning of Liff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: alexandrul @ 2009-10-18 15:29 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091018144158.GA9789@gandalf.dynalias.org>
Norbert Preining wrote:
> 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.
I was thinking to set a post-commit hook that reads the current version
from a file, increment and save it, and also set a tag with that value.
Being a DVCS, this kind of versioning can only be trusted on a single repo,
but if you set it on the "main" repo, it should work.
The only drawback could be the ever growing number of tags,
I don't know how it will work with thousands of tags or more.
Have a nice day,
A.
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-18 15:20 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200910181703.20607.johan@herland.net>
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.
> $ 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?
And if yes, is it easy to find out at which commit a file has been changed
last time (svn status -v).
I have read a lot on the net about the impossibility, and I agree that
in a distributed setting it does not work.
And in fact we would not even have revision numbers on our local
git repositories. Only one (the master checkout from which our
distribution server is updated) needs to have some commit numbers.
THe reason is that we use that as serial number for packages. One packages
is roughly on package from CTAN (Comprehensive TeX Archive Network,
like CPAN), and we want to make sure that if that is updated on CTAN
and we import it into our system, the next time we create a TeX Live
package for it (that will be served to quite a lot of users) we have
a new version number.
We first thought about using the version number as provided by authors,
but that is completely useless, because there are tooo many authors
of packages on CTAN where the version numbers are in no way increasing ;-)
So we settled for the max of all the last changed revision number of
the contained files, whcih is guaranteed to increase.
As a lat resort I will try to use git-svn ...
Again, 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
-------------------------------------------------------------------------------
QUOYNESS (n.)
The hatefulness of words like 'relionus' and 'easiephit'.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Johan Herland @ 2009-10-18 15:03 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091018144158.GA9789@gandalf.dynalias.org>
On Sunday 18 October 2009, Norbert Preining wrote:
> 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.
>
> So, before I delve into more gitty-nitty conversion, let me know if
> there is any chance for that, or we should stay with subversion.
A global, increasing version number ala SVN is fundamentally impossible in
any distributed version control system (like Git).
However, you can get a useful version specifier from the "git describe"
command. It will give you back something like the following:
$ 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
state, and the "2414721" is the abbreviated object name (SHA1 id) for the
current commit itself.
This is somewhat more complex than a simple version number, but guarantees a
globally unique name for your current state that works in a distributed
environment.
Also, I find "v1.0.4-14..." (i.e. 14 commits since v1.0.4) much more useful
than, say, "12534" (i.e. 12534 commits since the start of the project).
See 'git help describe for more info'
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-18 14:41 UTC (permalink / raw)
To: git
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.
So, before I delve into more gitty-nitty conversion, let me know if
there is any chance for that, or we should stay with subversion.
Thanks a lot and all the best
Norbert
PS: for those interested, it is TeX Live: www.tug.org/texlive
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
YONKERS (n.)
(Rare.) The combined thrill of pain and shame when being caught in
public plucking your nostril-hairs and stuffing them into your
side-pocket.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Alex Riesen @ 2009-10-18 12:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7v63adxh9a.fsf_-_@alter.siamese.dyndns.org>
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?
^ permalink raw reply
* Re: [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Björn Steinbrink @ 2009-10-18 12:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <20091018193448.6117@nanako3.lavabit.com>
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.
Björn
^ permalink raw reply
* Re: [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Nanako Shiraishi @ 2009-10-18 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7vaazpxha4.fsf_-_@alter.siamese.dyndns.org>
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'?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v3.1 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Nanako Shiraishi @ 2009-10-18 10:34 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091018071829.GA7748@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>
> On Sat, Oct 17, 2009 at 04:48:11PM +0200, Thomas Rast wrote:
>
>> > +NOTE: Some placeholders may depend on other options given to the
>> > +revision traversal engine. For example, the `%g*` reflog options will
>> > +insert an empty string unless we are traversing reflog entries (e.g., by
>> > +`git log -g`). The `%d` placeholder will use the "short" decoration
>> > +format if `--decorate` was not already provided on the command line.
>>
>> Sure. I figured it was obvious enough, but since you already went to
>> the lengths of documenting the exact behaviour of %d, I squashed it
>> and adjusted the acknowledgement in the commit message accordingly.
>
> If the consensus (or Junio's decision when applying) is that we don't
> need it, I don't mind if my suggestion is scrapped (or reworded).
I think your clarification is a good addition.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 0/3] Generalized "string function" syntax
From: René Scharfe @ 2009-10-18 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63ad5o8p.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> I mentioned an idea to enhance the pretty=format language with a
>>> string function syntax that people can extend by adding new functions
>>> in one of the "What's cooking" messages earlier. The general syntax
>>> would be like
>>>
>>> %[function(args...)any string here%]
>>>
>>> where "any string here" part would have the usual pretty=format
>>> strings. E.g. git show -s --format='%{w(72,8,4)%s%+b%]' should give
>>> you a line wrapped commit log message if w(width,in1,in2) is such a
>>> function.
>> I pondered line wrapping with format strings briefly a long time ago, and
>> I always considered it to be more similar to a colour, i.e. a state that
>> one can change and that is applied to all following text until the next
>> state change. (Except that it's always reset at the end of the format
>> string.) The example above would then turn into '%w(72,8,4)%s%+b'.
>
> As a syntax to express "wrapping" behaviour alone, I think this is much
> simpler and more superiour. I guess with this if you want to wrap
> something to 72 columns and then wrap something else to 66 columns, you
> would write '%w(72,8,4)something%w(66,8,4)something else', right?
That's right.
> I used %] only for two reasons.
>
> - Without an explicit "here it ends", I couldn't come up with a good way
> to express '%[w(72,8,4)something%]something else'. IOW, how I can say
> "wrap something to 72 columns and then place something else without any
> wrapping"?
My patch makes '%w()' reset the wrapping parameters to their defaults.
> - When we need to support more than one string function like this, it is
> unclear what '%f()one string%g()another one' in your syntax means.
> Does it mean '%[f()one string%]%[g()another one%]' (i.e. concatenate
> the result of applying string function f to 'one string' and the result
> of applying string function g to 'another one')? Or does it mean
> '%[f()one string%[g()another one%]%]' (apply 'f' to concatenation of
> 'one string' and the result of applying 'g' to 'another one')?
I was going to say that we already have something like that with %C, and
that the natural way (to me) is to apply them both, independently. Case
modification functions (upper, lower, capitalized) could be treated the
same way -- as state changes (like pressing caps lock when typing text).
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?
But then something else hit me: the line wrap function needs to consider
colour codes as having a length of zero. Ugh.
René
^ permalink raw reply
* [PATCH 3/3] git checkout --nodwim
From: Junio C Hamano @ 2009-10-18 8:01 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jay Soffian
In-Reply-To: <7vzl7pyvzl.fsf@alter.siamese.dyndns.org>
Porcelains may want to make sure their calls to "git checkout" will
reliably fail regardless of the presense of random remote tracking
branches by the new DWIMmery introduced.
Luckily all existing in-tree callers have extra checks to make sure they
feed local branch name when they want to switch, or they explicitly ask
to detach HEAD at the given commit, so there is no need to add this option
for them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fb7e68a..6ec9b83 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -616,6 +616,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
struct tree *source_tree = NULL;
char *conflict_style = NULL;
int patch_mode = 0;
+ int dwim_new_local_branch = 1;
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "new branch", "branch"),
@@ -631,6 +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_END(),
};
int has_dash_dash;
@@ -715,6 +718,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
if (!patch_mode &&
+ dwim_new_local_branch &&
opts.track == BRANCH_TRACK_UNSPECIFIED &&
!opts.new_branch &&
!check_filename(NULL, arg) &&
--
1.6.5.1.95.g09fbd
^ permalink raw reply related
* [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Junio C Hamano @ 2009-10-18 8:01 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jay Soffian
In-Reply-To: <7vzl7pyvzl.fsf@alter.siamese.dyndns.org>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d050c37..fb7e68a 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -572,6 +572,40 @@ static int interactive_checkout(const char *revision, const char **pathspec,
return run_add_interactive(revision, "--patch=checkout", pathspec);
}
+struct tracking_name_data {
+ const char *name;
+ char *remote;
+ int unique;
+};
+
+static int check_tracking_name(const char *refname, const unsigned char *sha1,
+ int flags, void *cb_data)
+{
+ struct tracking_name_data *cb = cb_data;
+ const char *slash;
+
+ if (prefixcmp(refname, "refs/remotes/"))
+ return 0;
+ slash = strchr(refname + 13, '/');
+ if (!slash || strcmp(slash + 1, cb->name))
+ return 0;
+ if (cb->remote) {
+ cb->unique = 0;
+ return 0;
+ }
+ cb->remote = xstrdup(refname);
+ return 0;
+}
+
+static const char *unique_tracking_name(const char *name)
+{
+ struct tracking_name_data cb_data = { name, NULL, 1 };
+ for_each_ref(check_tracking_name, &cb_data);
+ if (cb_data.unique)
+ return cb_data.remote;
+ free(cb_data.remote);
+ return NULL;
+}
int cmd_checkout(int argc, const char **argv, const char *prefix)
{
@@ -630,8 +664,6 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
opts.new_branch = argv0 + 1;
}
- if (opts.track == BRANCH_TRACK_UNSPECIFIED)
- opts.track = git_branch_track;
if (conflict_style) {
opts.merge = 1; /* implied */
git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
@@ -655,6 +687,11 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
* With no paths, if <something> is a commit, that is to
* switch to the branch or detach HEAD at it.
*
+ * With no paths, if <something> is _not_ a commit, no -t nor -b
+ * was given, and there is a tracking branch whose name is
+ * <something> in one and only one remote, then this is a short-hand
+ * to fork local <something> from that remote tracking branch.
+ *
* Otherwise <something> shall not be ambiguous.
* - If it's *only* a reference, treat it like case (1).
* - If it's only a path, treat it like case (2).
@@ -677,7 +714,20 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (get_sha1(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
- goto no_reference; /* case (3 -> 2) */
+ if (!patch_mode &&
+ opts.track == BRANCH_TRACK_UNSPECIFIED &&
+ !opts.new_branch &&
+ !check_filename(NULL, arg) &&
+ argc == 1) {
+ const char *remote = unique_tracking_name(arg);
+ if (!remote || get_sha1(remote, rev))
+ goto no_reference;
+ opts.new_branch = arg;
+ arg = remote;
+ /* DWIMmed to create local branch */
+ }
+ else
+ goto no_reference;
}
/* we can't end up being in (2) anymore, eat the argument */
@@ -715,6 +765,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
}
no_reference:
+
+ if (opts.track == BRANCH_TRACK_UNSPECIFIED)
+ opts.track = git_branch_track;
+
if (argc) {
const char **pathspec = get_pathspec(prefix, argv);
--
1.6.5.1.95.g09fbd
^ permalink raw reply related
* [PATCH 1/3] check_filename(): make verify_filename() callable without dying
From: Junio C Hamano @ 2009-10-18 8:00 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jay Soffian
In-Reply-To: <7vzl7pyvzl.fsf@alter.siamese.dyndns.org>
Make it possible to invole the logic of verify_filename() to make sure the
pathname arguments are unambiguous without actually dying. The caller may
want to do something different.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 1 +
setup.c | 38 ++++++++++++++++++++------------------
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/cache.h b/cache.h
index 96840c7..71a731d 100644
--- a/cache.h
+++ b/cache.h
@@ -396,6 +396,7 @@ extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
extern const char *prefix_path(const char *prefix, int len, const char *path);
extern const char *prefix_filename(const char *prefix, int len, const char *path);
+extern int check_filename(const char *prefix, const char *name);
extern void verify_filename(const char *prefix, const char *name);
extern void verify_non_filename(const char *prefix, const char *name);
diff --git a/setup.c b/setup.c
index 029371e..f67250b 100644
--- a/setup.c
+++ b/setup.c
@@ -61,6 +61,19 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
return path;
}
+int check_filename(const char *prefix, const char *arg)
+{
+ const char *name;
+ struct stat st;
+
+ name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
+ if (!lstat(name, &st))
+ return 1; /* file exists */
+ if (errno == ENOENT || errno == ENOTDIR)
+ return 0; /* file does not exist */
+ die_errno("failed to stat '%s'", arg);
+}
+
/*
* Verify a filename that we got as an argument for a pathspec
* entry. Note that a filename that begins with "-" never verifies
@@ -70,18 +83,12 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
*/
void verify_filename(const char *prefix, const char *arg)
{
- const char *name;
- struct stat st;
-
if (*arg == '-')
die("bad flag '%s' used after filename", arg);
- name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
- if (!lstat(name, &st))
+ if (check_filename(prefix, arg))
return;
- if (errno == ENOENT)
- die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
- "Use '--' to separate paths from revisions", arg);
- die_errno("failed to stat '%s'", arg);
+ die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
+ "Use '--' to separate paths from revisions", arg);
}
/*
@@ -91,19 +98,14 @@ void verify_filename(const char *prefix, const char *arg)
*/
void verify_non_filename(const char *prefix, const char *arg)
{
- const char *name;
- struct stat st;
-
if (!is_inside_work_tree() || is_inside_git_dir())
return;
if (*arg == '-')
return; /* flag */
- name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
- if (!lstat(name, &st))
- die("ambiguous argument '%s': both revision and filename\n"
- "Use '--' to separate filenames from revisions", arg);
- if (errno != ENOENT && errno != ENOTDIR)
- die_errno("failed to stat '%s'", arg);
+ if (!check_filename(prefix, arg))
+ return;
+ die("ambiguous argument '%s': both revision and filename\n"
+ "Use '--' to separate filenames from revisions", arg);
}
const char **get_pathspec(const char *prefix, const char **pathspec)
--
1.6.5.1.95.g09fbd
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox