* Re: [PATCH v3 0/4] git-p4: Improve branch support
From: Vitor Antunes @ 2011-08-23 22:32 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110820191407.GD7135@arf.padd.com>
On Sat, Aug 20, 2011 at 8:14 PM, Pete Wyckoff <pw@padd.com> wrote:
> In particular, a clear case of how to set up the branches for
> the branchList example would be good. My minimal test did not
> exactly work.
Could you send me the list of steps you followed that resulted in git-p4
failing to detect the branches?
Thanks,
--
Vitor Antunes
^ permalink raw reply
* Re: Looking for a way to turn off/modify ref disambiguation
From: Junio C Hamano @ 2011-08-23 22:03 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com>
"Nathan W. Panike" <nathan.panike@gmail.com> writes:
> 1. If $GIT_DIR/<name> exists, that is what you mean
> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
> MERGE_HEAD and CHERRY_PICK_HEAD);
> 2. otherwise, refs/<name> if it exists;
> 3. otherwise, refs/tags/<refname> if it exists;
> 4. otherwise, refs/heads/<name> if it exists;
> 5. otherwise, refs/remotes/<name> if it exists;
> 6. otherwise, refs/remotes/<name>/HEAD if it exists.
> ...
>
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error?
You will force people to say "git log origin/master..master" to measure
their progress if you did so, when "git log origin..master" has been the
way described in many git books and documentation pages floating on the
web.
I think it is _very_ unlikely that such a change is going to happen.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import
From: Vitor Antunes @ 2011-08-23 22:02 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110823022713.GA6005@arf.padd.com>
On Tue, Aug 23, 2011 at 3:27 AM, Pete Wyckoff <pw@padd.com> wrote:
> I think I understand the problem now, and have a small test case
> to see what's going wrong. Your solution is definitely
> sub-optimal. :) Is there anything that can be done with
> --import-marks and --export-marks?
Don't know if you agree, but I think it would be better to keep git-p4
from storing extra files in the filesystem. And, as far as I understood,
these two options require extra files.
But I don't think marks would help us that much. We already have
something similar: the changelist number in the commit log. The big
problem is that P4 does not store a pointer to the previous changelist.
> Could you guess at the branch point using p4? I.e. for each file
> in the new branch, grab the change that caused its most recent
> revision (the #xx part). Pick the max of those changes. In git,
> find the commit whith "change = ..." that you just discovered.
> That's the parent.
Yes, I think this would work. Nevertheless, I would prefer not to do so
much pooling on the P4 server because when we're in a remote location in
regards to the P4 proxy server this kind of command becomes rather slow.
And if the branch has many files this may become cumbersome.
> Even this won't be perfect, and I'm not even sure if it's less
> icky than diff-tree.
From what I can see, the two possible solutions would be:
a) Running a "filelog" on all files. This may become slower when the
branch has lots of files. There's also the problem in needing to
contact the P4 proxy server every time.
b) Using diff-tree. This will be slower if the original changelist is
very far from the latest one, but has the advantage of being run
locally. It has the disadvantage of not having an apparent
compatibility with fast-import.
In my personal point of view, diff-tree solution still looks better, if
it weren't for the fast-import issue. Now if we could just figure out
how to overcome this issue...
--
Vitor Antunes
^ permalink raw reply
* Re: [PATCH] Documentation: Grammar correction, wording fixes and cleanup
From: Junio C Hamano @ 2011-08-23 21:48 UTC (permalink / raw)
To: Drew Northup; +Cc: Ben Walton, git
In-Reply-To: <1314134106.5186.64.camel@drew-northup.unet.maine.edu>
Drew Northup <drew.northup@maine.edu> writes:
> On Mon, 2011-08-22 at 20:48 -0400, Ben Walton wrote:
>
>> +. You could be using the `objects/info/alternates` or
>> +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
>> objects from other object stores. A repository with this kind
>> of incomplete object store is not suitable to be published for
>> -use with dumb transports but otherwise is OK as long as
>> -`objects/info/alternates` points at the right object stores
>> -it borrows from.
>> +use with dumb transports but is otherwise OK as long as
>> +`objects/info/alternates` points to object stores containing the
>> +missing objects.
>
> Umm, I'm not prepared to call this an improvement. The objects aren't
> _missing_, they just aren't present in the most immediate object store.
> I'm a minimalist when it comes to this sort of edit and would have just
> excised the word "right" from the awkward segment.
Yeah, "points at the object stores it borrows objects from" sounds
readable and technically correct.
^ permalink raw reply
* Re: [PATCH 0/2] Add an update=none option for 'loose' submodules
From: Junio C Hamano @ 2011-08-23 21:46 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Heiko Voigt, Junio C Hamano, git
In-Reply-To: <4E540B03.2030909@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> It might surprise people. E.g. when their old scripts don't work anymore as
> they did before because a submodule won't be populated or updated in the work
> tree even though it is present in .git/config. So I agree that this should be
> documented in the release notes so people can check if their expectations are
> still met.
Worse yet, their custom old scripts that they use to update submodules in
their repository, if properly written, assume that anything registered in
the .git/config file as [submodule "foo"] _must_ be populated, but they
can no longer assume that and now has to look at submodule.foo.update and
if it notices the variable is set to "none" leave the submodule repository
alone. Having "submodule.foo" registered in the .git/config file alone
used to mean the user is interested in "foo" submodule and wants to have a
checkout for it, now it does not necessarily mean that.
That is definitely a huge semantics change.
^ permalink raw reply
* Re: [PATCH] Documentation: Grammar correction, wording fixes and cleanup
From: Drew Northup @ 2011-08-23 21:15 UTC (permalink / raw)
To: Ben Walton; +Cc: gitster, git
In-Reply-To: <1314060519-24035-1-git-send-email-bwalton@artsci.utoronto.ca>
On Mon, 2011-08-22 at 20:48 -0400, Ben Walton wrote:
> +. You could be using the `objects/info/alternates` or
> +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
> objects from other object stores. A repository with this kind
> of incomplete object store is not suitable to be published for
> -use with dumb transports but otherwise is OK as long as
> -`objects/info/alternates` points at the right object stores
> -it borrows from.
> +use with dumb transports but is otherwise OK as long as
> +`objects/info/alternates` points to object stores containing the
> +missing objects.
Umm, I'm not prepared to call this an improvement. The objects aren't
_missing_, they just aren't present in the most immediate object store.
I'm a minimalist when it comes to this sort of edit and would have just
excised the word "right" from the awkward segment.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Looking for a way to turn off/modify ref disambiguation
From: Jeff King @ 2011-08-23 21:15 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com>
On Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:
> 1. If $GIT_DIR/<name> exists, that is what you mean
> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
> MERGE_HEAD and CHERRY_PICK_HEAD);
> 2. otherwise, refs/<name> if it exists;
> 3. otherwise, refs/tags/<refname> if it exists;
> 4. otherwise, refs/heads/<name> if it exists;
> 5. otherwise, refs/remotes/<name> if it exists;
> 6. otherwise, refs/remotes/<name>/HEAD if it exists.
> ...
>
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error? Say, by setting a config option?
You can remove the remote HEAD reference with:
git remote set-head origin -d
That will only fix that particular repo, though. There is no config
option to disable it for all newly cloned repos.
-Peff
^ permalink raw reply
* Re: [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules
From: J.H. @ 2011-08-23 20:40 UTC (permalink / raw)
To: Sylvain Rabot
Cc: Jakub Narebski, git, John 'Warthog9' Hawley, Petr Baudis,
Pavan Kumar Sunkara, Alejandro R. Sedeno
In-Reply-To: <1314131735.3120.3.camel@kheops>
Pretty much stalled like most things on gitweb. I've been knee deep in
a lot of GSoC stuff, conferences and dealing with kernel bugs and Jakub
has been busy on other things so we haven't had a solid head bashing
session to get this all worked out yet.
Maybe while I'm over in Prague / Europe for KS & Linuxcon we can hash
things out.
- John 'Warthog9' Hawley
On 08/23/2011 01:35 PM, Sylvain Rabot wrote:
> Hi,
>
> Just wanted to know what is the current status of splitting gitweb
> sources into modules.
>
> Regards.
>
> On Tue, 2011-05-03 at 16:04 +0200, Jakub Narebski wrote:
>> Gitweb is currently next to largest file (after gitk) in git sources,
>> more than 225KB with more than 7,000 lines. Therefore adding any
>> large feature that would require large amount of code added, like
>> gitweb caching by J.H. and my rewrite of it, or "gitweb admin/write"
>> [failed] GSoC 2010 project by Pavan Kumar Sunkara, would require for
>> new code to be added as a separate module. Otherwise gitweb would
>> fast become unmaintainable.
>>
>> Note that there is already patch series sent which as one of side
>> effects splits the JavaScript side of gitweb into many smaller
>> self-contained files:
>>
>> [PATCH 03/13] gitweb: Split JavaScript for maintability, combining on build
>> http://thread.gmane.org/gmane.comp.version-control.git/172384/focus=172385
>>
>> Not in all cases splitting gitweb upfront would be required. At least
>> in the case of gitweb caching it doesn't. What must be done however
>> is preparing the infrastructure for modular gitweb sources; to
>> properly test such infrastructure we need at least one split gitweb
>> module. With patch series preparing for splitting or true splitting of
>> gitweb sent upfront the future patch series that implements
>> code-extensive feature (like e.g. output caching) would be smaller and
>> easier to review.
>>
>>
>> This series is intended to bring such infrastructure to gitweb, to
>> prepare way for adding output caching to gitweb. Alternatively it can
>> be thought as beginning of splitting gitweb into smaller submodules,
>> for better maintainability.
>>
>> This patch series was sent to git mailing list as
>>
>> [PATCH 0/2] gitweb: Begin splitting gitweb
>> http://thread.gmane.org/gmane.comp.version-control.git/165824
>>
>> In the above mentioned first version of this series, the first patch
>> that prepared the way for splitting gitweb was in three versions: A, B
>> and C. In this second version of this series the first patch in
>> series most closely resembles version C in v1 series.
>>
>> In this version gitweb uses _both_ 'use lib __DIR__."/lib";' and
>> 'use lib "++GITWEBLIBDIR++";', in correct order (as compared to
>> version C of v1 series), so that __DIR__."/lib" is checked first,
>> i.e. modules installed alongside gitweb.cgi win.
>>
>> Pull request:
>> ~~~~~~~~~~~~~
>> This series is available in the git repository at:
>> git://repo.or.cz/git/jnareb-git.git gitweb/split
>> git://github.com/jnareb/git.git gitweb/split
>>
>> Well, those patches has a few minor cosmetic fixups...
>>
>> Table of contents:
>> ~~~~~~~~~~~~~~~~~~
>> * [PATCHv2 1/2] gitweb: Prepare for splitting gitweb
>> [PATCHv2 2/2] gitweb: Create Gitweb::Util module
>>
>> First patch implements infrastructure, second proof of concept patch uses
>> this infrastructure, testing it ("make -C gitweb test-installed").
>>
>> Shortlog:
>> ~~~~~~~~~
>> Jakub Narebski (1):
>> gitweb: Prepare for splitting gitweb
>>
>> Pavan Kumar Sunkara (1):
>> gitweb: Create Gitweb::Util module
>>
>> Diffstat:
>> ~~~~~~~~~
>> gitweb/INSTALL | 7 ++
>> gitweb/Makefile | 23 ++++++-
>> gitweb/gitweb.perl | 151 ++++-----------------------------------
>> gitweb/lib/Gitweb/Util.pm | 177 +++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 219 insertions(+), 139 deletions(-)
>> create mode 100755 gitweb/lib/Gitweb/Util.pm
>>
>
^ permalink raw reply
* Re: [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules
From: Sylvain Rabot @ 2011-08-23 20:35 UTC (permalink / raw)
To: Jakub Narebski
Cc: Sylvain Rabot, git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley, Petr Baudis, Pavan Kumar Sunkara,
Alejandro R. Sedeno
In-Reply-To: <1304431450-23901-1-git-send-email-jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]
Hi,
Just wanted to know what is the current status of splitting gitweb
sources into modules.
Regards.
On Tue, 2011-05-03 at 16:04 +0200, Jakub Narebski wrote:
> Gitweb is currently next to largest file (after gitk) in git sources,
> more than 225KB with more than 7,000 lines. Therefore adding any
> large feature that would require large amount of code added, like
> gitweb caching by J.H. and my rewrite of it, or "gitweb admin/write"
> [failed] GSoC 2010 project by Pavan Kumar Sunkara, would require for
> new code to be added as a separate module. Otherwise gitweb would
> fast become unmaintainable.
>
> Note that there is already patch series sent which as one of side
> effects splits the JavaScript side of gitweb into many smaller
> self-contained files:
>
> [PATCH 03/13] gitweb: Split JavaScript for maintability, combining on build
> http://thread.gmane.org/gmane.comp.version-control.git/172384/focus=172385
>
> Not in all cases splitting gitweb upfront would be required. At least
> in the case of gitweb caching it doesn't. What must be done however
> is preparing the infrastructure for modular gitweb sources; to
> properly test such infrastructure we need at least one split gitweb
> module. With patch series preparing for splitting or true splitting of
> gitweb sent upfront the future patch series that implements
> code-extensive feature (like e.g. output caching) would be smaller and
> easier to review.
>
>
> This series is intended to bring such infrastructure to gitweb, to
> prepare way for adding output caching to gitweb. Alternatively it can
> be thought as beginning of splitting gitweb into smaller submodules,
> for better maintainability.
>
> This patch series was sent to git mailing list as
>
> [PATCH 0/2] gitweb: Begin splitting gitweb
> http://thread.gmane.org/gmane.comp.version-control.git/165824
>
> In the above mentioned first version of this series, the first patch
> that prepared the way for splitting gitweb was in three versions: A, B
> and C. In this second version of this series the first patch in
> series most closely resembles version C in v1 series.
>
> In this version gitweb uses _both_ 'use lib __DIR__."/lib";' and
> 'use lib "++GITWEBLIBDIR++";', in correct order (as compared to
> version C of v1 series), so that __DIR__."/lib" is checked first,
> i.e. modules installed alongside gitweb.cgi win.
>
> Pull request:
> ~~~~~~~~~~~~~
> This series is available in the git repository at:
> git://repo.or.cz/git/jnareb-git.git gitweb/split
> git://github.com/jnareb/git.git gitweb/split
>
> Well, those patches has a few minor cosmetic fixups...
>
> Table of contents:
> ~~~~~~~~~~~~~~~~~~
> * [PATCHv2 1/2] gitweb: Prepare for splitting gitweb
> [PATCHv2 2/2] gitweb: Create Gitweb::Util module
>
> First patch implements infrastructure, second proof of concept patch uses
> this infrastructure, testing it ("make -C gitweb test-installed").
>
> Shortlog:
> ~~~~~~~~~
> Jakub Narebski (1):
> gitweb: Prepare for splitting gitweb
>
> Pavan Kumar Sunkara (1):
> gitweb: Create Gitweb::Util module
>
> Diffstat:
> ~~~~~~~~~
> gitweb/INSTALL | 7 ++
> gitweb/Makefile | 23 ++++++-
> gitweb/gitweb.perl | 151 ++++-----------------------------------
> gitweb/lib/Gitweb/Util.pm | 177 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 219 insertions(+), 139 deletions(-)
> create mode 100755 gitweb/lib/Gitweb/Util.pm
>
--
Sylvain Rabot <sylvain@abstraction.fr>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Jens Lehmann @ 2011-08-23 20:30 UTC (permalink / raw)
To: PJ Weisberg
Cc: Thomas Rast, rdiezmail-temp2, git@vger.kernel.org,
in-git-vger@baka.org
In-Reply-To: <CAJsNXTk0LaSDKCOzJgZRLYmGe8hauPbPOw4oKLKP0Xr0axZkwg@mail.gmail.com>
Am 23.08.2011 12:04, schrieb PJ Weisberg:
> On Tue, Aug 23, 2011 at 2:17 AM, Thomas Rast <trast@student.ethz.ch> wrote:
>
>> I personally think that's crazy and -- if you want to avoid the work
>> of "really" using submodules -- support Jens's suggestion of having
>> the buildbot automatically assemble an "I tested this" superproject.
>
> Or create a tag in each separate repository, using the same tag name
> to indicate versions that were tested together. Or you could do the
> same with a branch, since a branch is basically a tag that moves. You
> would just have to make sure only the buildbot updated that branch.
That would also work, but it might need some scripting. Probably having
some server side hooks to enforce the policy allowing no-one except the
buildbot to change those branches/tags would help here. Also submodules
would make it easier to see when they differ from the commits recorded
in the superproject, so a script running something like "git describe"
in all local repos and displaying the results might be a good idea to
get that information.
^ permalink raw reply
* Re: [PATCH 0/2] Add an update=none option for 'loose' submodules
From: Jens Lehmann @ 2011-08-23 20:18 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git
In-Reply-To: <20110823194350.GA57187@book.hvoigt.net>
Am 23.08.2011 21:43, schrieb Heiko Voigt:
> On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:
>>> It is somewhat worrying that some parts of the system may still be using
>>> that old criteria "do we have it in .git/config of the superproject?" to
>>> decide if the user is interested in the submodule. If so they need to be
>>> updated to take this new semantics "do we have it in .git/config without
>>> its submodule.$name.update set to none" into account. We would probably
>>> need to have a paragraph in the release notes to warn about the semantics
>>> change (which I tend to agree with you that it is a good one).
>
> Sorry that I forgot to answer to this. I am not sure what you mean by
> "the semantics change". This patch does not change any existing
> behavior. I rather see this as an extra way to specify the default
> behavior of what happens on submodule update. If people do not use it
> there will be no expectations broken.
It might surprise people. E.g. when their old scripts don't work anymore as
they did before because a submodule won't be populated or updated in the work
tree even though it is present in .git/config. So I agree that this should be
documented in the release notes so people can check if their expectations are
still met.
> Another change I am thinking of (which would definitely need an entry in
> the release notes) is to change submodule foreach to iterate over all
> gitmodule entries in the index/HEAD/worktree (not sure yet) instead of
> "just entries that are in .git/config".
When changing the default I think we'll surprise a lot of users (imagine
someone running a "git submodule foreach pwd" when some submodules aren't
populated). But adding an option to "git submodule foreach" (and maybe others)
to get the list of submodules from the index or HEAD might make sense (while
I'm not sure parsing the work tree does, as you'll basically have to pick up
any .git you find. AFAICS a submodule is defined either by an entry in the
.gitmodules file, in .git/config or through a gitlink entry in a commit or the
index. So maybe the third alternative to index and HEAD is to use those found
in .gitmodules?).
Could you describe a use case for that?
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Michael J Gruber @ 2011-08-23 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marat Radchenko, git
In-Reply-To: <7vk4a4rqvb.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 23.08.2011 19:15:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Marat Radchenko venit, vidit, dixit 23.08.2011 12:52:
>>>> Is that a very large tree or a very slow file system?
>>> Tree is large (500k files), file system is irrelevant since all time is spend on CPU.
>>>
>>>> Do we enumerate all
>>>> differing files and only then limit diff output by path??
>>>
>>> Dunno, that's why I am asking why it is so slow.
>>
>> Well, we have to read the full tree before diffing.
>
> Not necessarily, especially when pathspec is given like the original post,
> i.e. "git diff $tree_ish -- $path". We would need to open tree objects
> that lead to the leaf of the $path and a blob, but other objects won't be
> needed.
I meant: The way "git diff" is now, it does that.
>
> The default diff backend tries to come up with minimal changes by spending
> extra cycles, so it is not so surprising if the file compared is large-ish
> and/or has very many similar lines in itself (in which case there are many
> potential matching line pairs between the preimage and the postimage to be
> examined to produce a minimal diff).
But the file in this case is not that large, and "git diff" spends 30s!
Michael
^ permalink raw reply
* Re: [PATCH] git-svn: Destroy the cache when we fail to read it
From: Eric Wong @ 2011-08-23 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jason Gross, git, Jonathan Nieder
In-Reply-To: <7vobzgrrbg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Jason Gross <jgross@MIT.EDU> wrote:
> >> my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
> >
> > Can we make the caches sharable by encoding variables like
> > $Config{use64bitint} and $Storable::VERSION into $cache_path?
> >
> > Something like this (untested):
> >
> > use Config;
> >
> > my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
> > $cache_path .= "$Config{use64bitint}.$Storable::VERSION/";
> >
> > We'll blow everybody's cache away once during the git-svn upgrade, but
> > in the future people will be able to share the same working tree between
> > different versions of perl/Storable/whatnot without needing extra code
> > to detect croaks, different build options, and nuking each other's
> > caches.
>
> Meaning multiple directories and people share with those with systems with
> similar characteristics?
Yes.
> It certainly is better than silently getting confused or barfing when
> reading 32LE data on 64BE box, and presumably it would be easy to
> implement, but is that the best we can do with memoize?
>
> I am wondering if memoize can be told to use a platform independent
> serializer backend that is reasonably efficient.
Storable nstore only guarantees endian-neutrality. JSON/YAML/XML are
all platform-neutral options but (AFAIK) none are standard parts of all
Perl versions we support. There's Data::Dumper + eval which should
work, but a Memoize::* interface needs to be implemented/imported.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v4 1/2] push: Don't push a repository with unpushed submodules
From: Heiko Voigt @ 2011-08-23 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Gustafsson, git, jens.lehmann
In-Reply-To: <7vd3fxulw8.fsf@alter.siamese.dyndns.org>
On Mon, Aug 22, 2011 at 03:22:31PM -0700, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
> > Junio since you are one person listed in the api docs could you maybe
> > quickly explain to me what this flag is used for?
>
> It is used in order to avoid walking the object we have walked already.
>
> Which in turn means that once you walk chain of objects, unless you
> remember the ones you walked and clear the marks after you are done, you
> cannot walk the object chain for unrelated purposes. See how functions
> like get_merge_bases_many() walk portions of graph for their own purpose
> and then avoid disrupting others by calling clear_commit_marks(). The use
> of TMP_MARK (and its clearing after the function is done with the marked
> objects) in remove_duplicate_parents() serve the same purpose.
Thanks I will have look at those places and try to cook up something.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH 0/2] Add an update=none option for 'loose' submodules
From: Heiko Voigt @ 2011-08-23 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7v62lpuky8.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:
> > On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:
> >> Heiko Voigt <hvoigt@hvoigt.net> writes:
> >> What I usually do is say "submodule init" without any extra option once.
> >> That will register all submodules from .gitmodules in the config. Now
> >> when I say "submodule update" all submodules would be cloned. In the
> >> case of recursive submodules actually
> >>
> >> git submodule update --init --recursive
> >>
> >> is the only command which can get you really everything in one go.
> >>
> >> Do you think the "submodule init" behavior is wrong? If so I think its a
> >> bit late to change this since people using submodules (me included)
> >> already have got used to it.
> >>
> >> With this config variable all submodules will still be registered to
> >> .git/config on "submodule init" but "submodule update" will skip those
> >> submodules.
> >
> > Ok, that sort-of makes sense, but we have been using "do we have the
> > submodule registered in the .git/config of the superproject?" to decide
> > "does the user interested in having a checkout of the submodule?" (I think
> > in the ancient days it was "do we have .git in that submodule directory?"
> > that decided it, but we dropped that because it won't work when switching
> > branches that has and does not have the submodule in superproject).
> >
> > It is somewhat worrying that some parts of the system may still be using
> > that old criteria "do we have it in .git/config of the superproject?" to
> > decide if the user is interested in the submodule. If so they need to be
> > updated to take this new semantics "do we have it in .git/config without
> > its submodule.$name.update set to none" into account. We would probably
> > need to have a paragraph in the release notes to warn about the semantics
> > change (which I tend to agree with you that it is a good one).
Sorry that I forgot to answer to this. I am not sure what you mean by
"the semantics change". This patch does not change any existing
behavior. I rather see this as an extra way to specify the default
behavior of what happens on submodule update. If people do not use it
there will be no expectations broken.
Another change I am thinking of (which would definitely need an entry in
the release notes) is to change submodule foreach to iterate over all
gitmodule entries in the index/HEAD/worktree (not sure yet) instead of
"just entries that are in .git/config".
What do you think?
Cheers Heiko
^ permalink raw reply
* Looking for a way to turn off/modify ref disambiguation
From: Nathan W. Panike @ 2011-08-23 19:26 UTC (permalink / raw)
To: git
A colleague at $dayjob recently caused corruption in our git
repository by accidentally running the command
git rebase origin stable
where they meant to run
git rebase origin/stable
The git-rev-parse(1) man page says:
...
<refname>, e.g. master, heads/master, refs/heads/master
A symbolic ref name. E.g. master typically means the commit object
referenced by refs/heads/master. If you happen to have both
heads/master and tags/master, you can explicitly say heads/master to
tell git which one you mean. When ambiguous, a <name> is disambiguated
by taking the first match in the following rules:
1. If $GIT_DIR/<name> exists, that is what you mean
(this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
MERGE_HEAD and CHERRY_PICK_HEAD);
2. otherwise, refs/<name> if it exists;
3. otherwise, refs/tags/<refname> if it exists;
4. otherwise, refs/heads/<name> if it exists;
5. otherwise, refs/remotes/<name> if it exists;
6. otherwise, refs/remotes/<name>/HEAD if it exists.
...
Is there any way to change this behavior, e.g., so that rule 6 becomes
an error? Say, by setting a config option?
==========
Nathan Panike
^ permalink raw reply
* Re: [PATCH 1/2] Prevent force-updating of the current branch
From: Conrad Irwin @ 2011-08-23 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v39gsrnuc.fsf@alter.siamese.dyndns.org>
On Tue, Aug 23, 2011 at 11:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Conrad Irwin <conrad.irwin@gmail.com> writes:
>
>> git branch -M <foo> <current-branch> could be used to change the branch
>> to which HEAD points, without the necessary house-keeping that git reset
>> normally does to make this operation sensible. It would leave the reflog
>> in a confusing state (you would be warned when trying to read it) and
>> had an apparently side-effect of staging the diff between <current branch>
>> and <foo>.
>
> The last two lines are redundant (it is "without the house-keeping of
> reset"); I'll remove "and had an apparently...".
That's fine by me.
>> git checkout -f already guarded against this problem, and aborted with
>> a fatal error.
>
> I assume you mean "branch -f". I'll rewrite it so, and in the present
> tense.
Yes. Thank you.
>
>> git branch -M, git checkout -B and git branch -f now use the same checks
>> before allowing a branch to be created. These prevent you from updating
>> the current branch.
>
> Looks good ;-). Also the patch looks good, too.
>
Glad to hear :).
Conrad
^ permalink raw reply
* Re: Merge after directory rename ?
From: Jeff King @ 2011-08-23 19:13 UTC (permalink / raw)
To: Michael Witten; +Cc: Marcin Wiśnicki, git
In-Reply-To: <CAMOZ1Bt8cP146xiDXfSA-naSOaS3AC8pUZgW12=3TMg2JGCD=w@mail.gmail.com>
On Sun, Aug 21, 2011 at 11:53:34PM +0000, Michael Witten wrote:
> This is because git fundamentally tracks content, and paths are just
> one kind of content associated with another blob of content.
> Consequently, git really knows next to nothing about directories, so
> it's not too surprising that git doesn't bother finding such a
> DIRECTORY rename anyway (at most, git would detect a FILE rename, and
> your FILE `dir1/file2' has nothing to do with, say, the FILE
> `dir1/file1' being renamed `dir2/file1').
>
> Still, some command line switches could be useful to help the user
> express to git what should be going on in a case such as yours.
FYI, Yann Dirson was working on some patches to detect directory
renames, but we haven't heard anything for a while. The last version I
could find was:
http://thread.gmane.org/gmane.comp.version-control.git/163328
-Peff
^ permalink raw reply
* Re: [PATCH v4 3/4] merge: remove global variable head[]
From: Junio C Hamano @ 2011-08-23 18:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313765407-29925-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -1012,9 +1014,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> {
> unsigned char result_tree[20];
> unsigned char stash[20];
> + unsigned char head[20];
> + struct commit *head_commit = NULL;
> struct strbuf buf = STRBUF_INIT;
> const char *head_arg;
> - int flag, head_invalid = 0, i;
> + int flag, i;
> int best_cnt = -1, merge_was_ok = 0, automerge_was_ok = 0;
> struct commit_list *common = NULL;
> const char *best_strategy = NULL, *wt_strategy = NULL;
> @@ -1030,8 +1034,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> branch = resolve_ref("HEAD", head, 0, &flag);
> if (branch && !prefixcmp(branch, "refs/heads/"))
> branch += 11;
> - if (is_null_sha1(head))
> - head_invalid = 1;
> + if (!is_null_sha1(head)) {
> + head_commit = lookup_commit(head);
> + if (!head_commit)
> + die(_("could not parse HEAD"));
> + }
Is this is_null_sha1() valid without first clearing head[]?
Also, would it be too much trouble and code churn to employ the same
strategy as my rewrite of your [1/4] and pass only head_commit around in
the call chain?
Because this is the way to set up head_commit in the first place, this
particular resolve_ref() -> is_null_sha1() chain is unavoidable and needs
to be written carefully, but after the
!head_commit === is_null_sha1(head) === is_initial_commit
invariant is established, I suspect that it would reduce the chance of
similar mistakes in later parts of the code if it can check and use only
one argument.
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: allow to tag newly created objects
From: Junio C Hamano @ 2011-08-23 18:32 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Jonathan Nieder, Shawn O. Pearce, David Barr
In-Reply-To: <1314015019-6636-3-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> } else if (!get_sha1(from, sha1)) {
> - type = sha1_object_info(sha1, NULL);
> - if (type < 0)
> - die("Not a valid object: %s", from);
> + struct object_entry *oe = find_object(sha1);
> + if (!oe) {
> + type = sha1_object_info(sha1, NULL);
> + if (type < 0)
> + die("Not a valid object: %s", from);
> + } else
> + type = oe->type;
It might be just a "taste" thing, but I would have expected the above to
be written like so:
struct object_entry *oe = find_object(sha1);
if (!oe)
type = sha1_object_info(sha1, NULL);
else
type = oe->type;
if (type < 0)
die("Not a valid object: %s", from);
The point being that find_object()->type and the return value of
sha1_object_info() are supposed to be compatible and interchangeably used,
which is exactly why the same variable "type" gets assigned and later be
used in the same codeflow, so they should get the same error checking,
even if it happens to be that the current implementation of find_object()
never returns an object with invalid type in it.
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Marat Radchenko @ 2011-08-23 18:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vk4a4rqvb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> Not necessarily, especially when pathspec is given like the original post,
> i.e. "git diff $tree_ish -- $path". We would need to open tree objects
> that lead to the leaf of the $path and a blob, but other objects won't be
> needed.
And git show branch:path already has that code.
^ permalink raw reply
* Re: [PATCH 1/2] Prevent force-updating of the current branch
From: Junio C Hamano @ 2011-08-23 18:20 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git, gitster
In-Reply-To: <1313876989-16328-2-git-send-email-conrad.irwin@gmail.com>
Conrad Irwin <conrad.irwin@gmail.com> writes:
> git branch -M <foo> <current-branch> could be used to change the branch
> to which HEAD points, without the necessary house-keeping that git reset
> normally does to make this operation sensible. It would leave the reflog
> in a confusing state (you would be warned when trying to read it) and
> had an apparently side-effect of staging the diff between <current branch>
> and <foo>.
The last two lines are redundant (it is "without the house-keeping of
reset"); I'll remove "and had an apparently...".
> git checkout -B <current branch> <foo> was also partly vulnerable to
> this bug; due to inconsistent pre-flight checks it would perform half of
> its task and then abort just before rewriting the branch. Again this
> manifested itself as the index file getting out-of-sync with HEAD.
>
> git checkout -f already guarded against this problem, and aborted with
> a fatal error.
I assume you mean "branch -f". I'll rewrite it so, and in the present
tense.
> git branch -M, git checkout -B and git branch -f now use the same checks
> before allowing a branch to be created. These prevent you from updating
> the current branch.
Looks good ;-). Also the patch looks good, too.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Junio C Hamano @ 2011-08-23 18:09 UTC (permalink / raw)
To: Ramsay Jones; +Cc: pascal, git, Johannes Sixt
In-Reply-To: <4E502302.4000300@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
> 05-08-2011) in pu needs an update to fix the commit message.
Thanks for a reminder, Ramsay.
Here is the exchange where fixing the commit log was mentioned.
From: Pascal Obry <pascal@obry.net>
Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: git@vger.kernel.org
Date: Sat, 13 Aug 2011 19:34:37 +0200
Message-ID: <4E46B5AD.5050806@obry.net>
Le 11/08/2011 22:35, Ramsay Jones a écrit :
> ... could you please correct your commit message. Thanks!
Done, thanks for your review.
> Also, I didn't see any response to Johannes Sixt's query concerning
> backslash in pathspec. (I personally don't want to go down that
> route, but ...)
Here is what J6t said in the message:
From: Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
Date: Tue, 09 Aug 2011 21:47:15 +0200
Message-ID: <4E418EC3.4070904@kdbg.org>
> Do you also want to support this:
> $ git add src\file.c
> i.e., backslash in pathspec? Then you need more than this:
> > +#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
> > +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
>
> In particular, you have to enable backslash processing in
> setup.c:prefix_filename(), but then you lose the ability to escape
> special characters with the backslash.
When "git add src\file.c" is given from the command line, what does our
main() see in argv[2]? Do cmd.exe and bash give us the same thing? What if
the command line is "git add 'src\*.c'"?
I vaguely recall that on Windows you only get a single parameter string
from the program loader, and arguments are split in the invoked process,
but that is so common that as far as our main() is concerned we can expect
the example command line to give us argc=3 and argv={ "git", "add", "???",
NULL }. What I do not recall is if there is some other magic such as
expanding shell globs and swapping the direction of slashes in strings
involved when this argument processing is done.
You probably _could_ do '\\' -> '/' inside prefix_filename() and
get_pathspec(), but as J6t mentioned, we _do_ handle backslash as a
quoting character, and this is _not_ going to change.
So even if we were to go that route, the user would need to make git see
"src\\file.c" or "src\\*.c" in order to make it turn into "src/file.c" and
"src/*.c" pathspec. If it means that the user needs to type:
$ git add src\\\\file.c
I would have to say that it would be simpler for them to say
$ git add src/file.c
even on Cygwin. After all, isn't Cygwin for people who are forced to be on
Windows and miss POSIXy environments?
By the way, Johannes, how does Git for Windows handle pathspecs?
^ permalink raw reply
* Re: [PATCH 4/4] Add documentation for ref namespaces
From: Junio C Hamano @ 2011-08-23 17:19 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jamey Sharp, Junio C Hamano, Shawn O. Pearce, Johannes Schindelin,
Jeff King, Jakub Narebski, git, Josh Triplett
In-Reply-To: <CACBZZX4bow8vwrwSL5uRJQtAgeg10_K+5ss8u-HvCHOn3+0Tuw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Tue, Jun 7, 2011 at 20:21, Jamey Sharp <jamey@minilop.net> wrote:
>
>> Document the namespace mechanism in a new gitnamespaces(7) page.
>> Reference it from receive-pack and upload-pack.
>
> This breaks the build on older asciidoc versions, the fix is to do
> what I did in f5008f56d5aba06598e1c6272f4f55b4ee4bb016.
Thanks for a sharp-eye, even though I would have appreciated it even more
if you spotted it while the series was still in 'next'.
Like this?
Documentation/gitnamespaces.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
index ed8924e..6e03946 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/gitnamespaces.txt
@@ -5,6 +5,11 @@ NAME
----
gitnamespaces - Git namespaces
+SYNOPSIS
+--------
+None (this section is to only please older version of AsciiDoc)
+
+
DESCRIPTION
-----------
^ permalink raw reply related
* Re: [RFH] lifetime rule for url parameter to transport_get()?
From: Daniel Barkalow @ 2011-08-23 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vsjosrs0w.fsf@alter.siamese.dyndns.org>
On Tue, 23 Aug 2011, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Does anybody remember why we use a copied string of "ref_git_copy" in
> > builtin/clone.c::setup_reference()?
> >
> > ref_git = real_path(option_reference);
> > ...
> > ref_git_copy = xstrdup(ref_git);
>
> It didn't have anything to do with transport/remote layer.
>
> This codepath uses real_path() and optionally mkpath(), both of which
> returns a short-lived static buffer to return its findings, and long-term
> users are expected to copy it away.
Yeah, that fits with my expectation, given the lack of a comment and the
fact that you were asking about clone and not also fetch.
At least originally, the remote and transport data was expected to live
until the process exits, since it's a small, bounded number of small
objects. If I'd included functions to free the structures, I'd have had
them free the strings they were passed.
-Daniel
*This .sig left intentionally blank*
^ 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