* Re: [PATCH] rebase -i: clean error message for --continue after failed exec
From: Junio C Hamano @ 2011-08-24 18:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1314194508-12067-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> If after a failed "exec" instruction there are staged changes,...
I have to wonder why whatever "exec" runs is mucking with the index in the
first place. Shouldn't we forbid it?
^ permalink raw reply
* Re: Buggy handling of non-canonical ref names
From: Junio C Hamano @ 2011-08-24 18:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list
In-Reply-To: <4E551D70.9080509@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> What is the policy about reference names and their canonicalization?
The overall policy has been that we care about well-formed input, and
everything else is "undefined", even though as you found out some of them
try to work sensibly.
> $ git check-ref-format /foo/bar ; echo $?
> 0
>
> $ git check-ref-format --print /foo/bar
> /foo/bar
I think these are bogus. Patches welcome.
> However, creating a reference with such a name is equivalent to creating
> a reference without the leading slash:
>
> $ git update-ref /foo/bar HEAD
> $ cat .git/foo/bar
> ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd
> $ git branch /bar/baz
> $ git for-each-ref | grep baz
> ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd commit refs/heads/bar/baz
These are just examples of "undefined being nice to the user as a bonus".
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Junio C Hamano @ 2011-08-24 18:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michael Schubert, Jeff King, git
In-Reply-To: <4E551AD0.7050702@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> As suggested, I've just called it "--glob" for now.
>
> Well, again, what's the point in replicating
>
> http://permalink.gmane.org/gmane.comp.version-control.git/172228
>
> and how is it different?
> As I've mentioned, I've been in the middle of polishing that up.
It is not unusual for a similar itch to happen to different people
independently.
If this were something you reposted even a WIP re-polish within the past
two weeks, I would understand and even sympathise with your irritation,
but please don't expect everybody to dig back FOUR MONTHS worth of mail
backlog to find an topic that may or may not be abandoned by the original
author. Perhaps we would need a weekly posting of topics people have
posted, found to be not quite ready yet, and are still being polished and
not abandoned [*1*]?
Having said that, I still appreciate that you posted a link to the
previous topic:
http://thread.gmane.org/gmane.comp.version-control.git/172226
so that the discussions in this thread to scratch the same "itch" can
benefit from the points raised in the previous thread that need to be
considered.
The old thread talks about renaming existing options and transition plans
to make the "listing" mode of "branch" and "tag" more similar, which may
be a good plan in the longer term.
I however can see that teaching "--glob" to both "branch" and "tag" (in
other words, "tag -l" would become a synonym for "tag --glob") an equally
good longer term plan.
[Footnote]
*1* It does not have to be a weekly _posting_ on the list but can be a
well-known Wiki page or even a bug tracker. Whatever medium is used for
this purpose, there _must_ be a built-in mechanism to expire entries away
that are inactive for more than some reasonable limit (say two to three
weeks).
^ permalink raw reply
* Re: master-master server setup
From: Drew Northup @ 2011-08-24 18:26 UTC (permalink / raw)
To: Corey Mitchell; +Cc: git, Sitaram Chamarty
In-Reply-To: <loom.20110824T191218-282@post.gmane.org>
On Wed, 2011-08-24 at 17:14 +0000, Corey Mitchell wrote:
> Hello Git team,
>
> We have a distributed team (US and Japan). We are thinking about migrating from
> subversion to git because it better suits our distributed team. Due to network
> latency, we want to setup 2 git servers hosting the same repository. We want
> developers to be able to download and publish branches to their local server and
> then have those changes replicated to the other site. Is this possible? Can
> someone please explain how this setup is done? If not, can someone please
> explain the closest alternative and how it is setup?
Corey,
If you choose to use gitolite, then you can just use Sitaram's
instructions here:
http://sitaramc.github.com/gitolite/doc/mirroring.html
If nothing else, you might find it inspirational.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: git for game development?
From: Jeff King @ 2011-08-24 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lawrence Brett, git
In-Reply-To: <7vwre2pw3m.fsf@alter.siamese.dyndns.org>
On Wed, Aug 24, 2011 at 10:17:49AM -0700, Junio C Hamano wrote:
> I suspect that people with large binary assets were scared away by rumors
> they heard second-hand, based on bad experiences other people had before
> any of the recent efforts made in various "large Git" topics, and they
> themselves haven't tried recent versions of Git enough to be able to tell
> what the remaining pain points are. I wouldn't be surprised if none of the
> core Git people tried shoving huge binary assets in test repositories with
> recent versions of Git---I certainly haven't.
I haven't tried anything really big in a while. My personal interest in
big file support has been:
1. Mid-sized photos and videos (objects top out around 50M, total repo
size is 4G packed). Most commits are additions or tweaks of exif
tags (so they delta well). Using gitattributes (and especially
textconv caching), it's really quite pleasant to use. Doing a full
repack is my only complaint; the delta-compression isn't bad, but
just the I/O on rewriting the whole thing is a killer.
2. Storing an entire audio collection in flac. Median file size is
only around 20M, but the whole repo is 120G. Obviously compression
doesn't buy much, so a git repo plus checkout is 240G, which is
pretty hefty for most laptops. I played with this early on, but
gave up; the data storage model just doesn't make sense.
The two common use cases that aren't represented here are:
3. Big files, not just big repos. I.e., files that are 1G or more.
4. Medium-big files that don't delta well (e.g., metadata tweaks do
delta well; rewriting media assets for a game don't delta well).
I think recent changes (like putting big files straight to packs) make
(3) and (4) reasonably pleasant.
I'm not sure of the right answer for (1). The repack is the only
annoying thing. But not repacking is not satisfying, either. You don't
get deltas where they are applicable, and the server is always
re-examining the pack for possible deltas on fetch and push. Some sort
of hybrid loose-pack storage would be nice: store delta chains for big
files in their own individual packs, but otherwise keep everything in a
separate pack. We would want some kind of meta-index over all of these
little pack-files, not just individual pack-file indices.
But (2) is the hardest one. It would be nice if we had some kind of
local-remote hybrid storage, where objects were fetched on demand from
somewhere else. For example, developers on workstations with a fast
local network to a storage server wouldn't have to replicate all of the
objects locally. And for a true distributed setup, when the fast network
isn't there, it would be nice to fail gracefully (which maybe just means
saying "sorry, we can't do 'log -p' right now; try 'log --raw'").
I wonder how close one can get on (2) using alternates and a
network-mounted filesystem.
> People toyed around with ideas to have a separate object store
> representation for large and possibly incompressible blobs (a possible
> complaint being that it is pointless to send them even to its own
> packfile). One possible implementation would be to add a new huge
> hierarchy under $GIT_DIR/objects/, compute the object name exactly the
> same way for huge blobs as we normally would (i.e. hash concatenation of
> object header and then contents) to decide which subdirectory under the
> "huge" hierarchy to store the data (huge/[0-9a-f]{2}/[0-9a-f]{38}/ like we
> do for loose objects, or perhaps huge/[0-9a-f]{40}/ expecting that there
> won't be very many). The data can be stored unmodified as a file in that
> directory, with type stored in a separate file---that way, we won't have
> to compress, but we just copy. You still need to hash it at least once to
> come up with the object name, but that is what gives us integrity checks,
> is unavoidable and is not going to change.
Yeah. I think one of the bonuses there is that some filesystems are
capable of referencing the same inodes in a copy-on-write way, so "add"
and "checkout" cease to be a copy operation, but rather an inode-linking
operation. Which is a big win, both for speed and storage.
I've had dreams of using hard-linking to do something similar, but it's
just not safe enough without some filesystem-level copy-on-write
protection.
-Peff
^ permalink raw reply
* Re: [PATCH] get_indexed_object can return NULL if nothing is in that slot; check for it
From: Junio C Hamano @ 2011-08-24 17:54 UTC (permalink / raw)
To: Brian Harring; +Cc: git
In-Reply-To: <20110824054717.GA16512@localhost>
Thanks for a fix.
It is both interesting and disturbing to see that these small mistakes are
discovered a week after the topics hit 'master', even though it has been
cooking in 'next' for a week before that happened (in the case of this
topic, it also hit 'maint' yesterday).
^ permalink raw reply
* Re: Looking for a way to turn off/modify ref disambiguation
From: Junio C Hamano @ 2011-08-24 17:48 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Nathan W. Panike, git
In-Reply-To: <4E54C373.1070702@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I haven't come across advice like that....
> I consider that advice very bad indeed:
>
> If "origin..master" is resolved to...
Perhaps origin..master was a bad example for you [*1*]; but the point is
you can say "origin" to mean the commit at the tip of the remote tracking
branch that the repository you cloned from deemed as its primary branch
anywhere we expect a commit on the command line.
So if you do not like "log origin..master", then say "git log origin"
instead and the point still stands.
[Footnote]
*1* "origin..master" is still a perfectly good example in tutorials to
teach people who use the workflow with a single at the central repository,
i.e. the simplest for esapee from CVS/SVN. You may have "frotz" topic and
"nitfol" topic branches locally cooking your own changes, and you can
measure their progress against the central repository with "origin..frotz"
and "origin..nitfol".
^ permalink raw reply
* master-master server setup
From: Corey Mitchell @ 2011-08-24 17:14 UTC (permalink / raw)
To: git
Hello Git team,
We have a distributed team (US and Japan). We are thinking about migrating from
subversion to git because it better suits our distributed team. Due to network
latency, we want to setup 2 git servers hosting the same repository. We want
developers to be able to download and publish branches to their local server and
then have those changes replicated to the other site. Is this possible? Can
someone please explain how this setup is done? If not, can someone please
explain the closest alternative and how it is setup?
Thanks a lot,
Corey
^ permalink raw reply
* Re: git for game development?
From: Junio C Hamano @ 2011-08-24 17:17 UTC (permalink / raw)
To: Jeff King; +Cc: Lawrence Brett, git
In-Reply-To: <20110824012418.GA19091@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't remember all of the details of bup, but if it's possible to
> implement something similar at a lower level (i.e., at the layer of
> packfiles or object storage), then it can be a purely local thing, and
> the compatibility issues can go away.
I tend to agree, and we might be closer than we realize.
I suspect that people with large binary assets were scared away by rumors
they heard second-hand, based on bad experiences other people had before
any of the recent efforts made in various "large Git" topics, and they
themselves haven't tried recent versions of Git enough to be able to tell
what the remaining pain points are. I wouldn't be surprised if none of the
core Git people tried shoving huge binary assets in test repositories with
recent versions of Git---I certainly haven't.
We used to always map the blob data as a whole for anything we do, but
these days, with changes like your abb371a (diff: don't retrieve binary
blobs for diffstat, 2011-02-19) and my recent "send large blob straight to
a new pack" and "stream large data out to the working tree without holding
everything in core while checking out" topics, I suspect that the support
for local usage of large blobs might be sufficiently better than the old
days. Git might even be usable locally without anything else, which I find
implausible, but I wouldn't be surprised if there remained only a handful
minor things remaining that we need to add to make it usable.
People toyed around with ideas to have a separate object store
representation for large and possibly incompressible blobs (a possible
complaint being that it is pointless to send them even to its own
packfile). One possible implementation would be to add a new huge
hierarchy under $GIT_DIR/objects/, compute the object name exactly the
same way for huge blobs as we normally would (i.e. hash concatenation of
object header and then contents) to decide which subdirectory under the
"huge" hierarchy to store the data (huge/[0-9a-f]{2}/[0-9a-f]{38}/ like we
do for loose objects, or perhaps huge/[0-9a-f]{40}/ expecting that there
won't be very many). The data can be stored unmodified as a file in that
directory, with type stored in a separate file---that way, we won't have
to compress, but we just copy. You still need to hash it at least once to
come up with the object name, but that is what gives us integrity checks,
is unavoidable and is not going to change.
The sha1_object_info() layer can learn to return the type and size from
such a representation, and you can further tweak the same places as the
"streaming checkout" and the "checkin to a pack" topics touched to support
such a representation.
I would suspect that the local object representation is _not_ the largest
pain point; such a separate object store representation is not buying us
very much over a simpler "single large blob in a separate packfile", and
if the counter-argument is "no, decompressing still costs a lot", then the
real issue might be we decompress and look at the data when we do not have
to (i.e. issues similar to what abb371a addressed), not "decompress vs
straight copy make a bit difference".
I would further suspect that we _might_ need a better support for local
repacking and object transfer, with or without such a third object
representation.
^ permalink raw reply
* Re: Looking for a way to turn off/modify ref disambiguation
From: Jonathan Nieder @ 2011-08-24 16:37 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Nathan W. Panike, git
In-Reply-To: <4E54C373.1070702@drmicha.warpmail.net>
Michael J Gruber wrote:
> "@{u}.." does that when you're on the branch in
> question, and we have no notation for "@{u(master)}..master".
"master@{u}..master" works, though it's not very short.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Michael Witten @ 2011-08-24 16:18 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Andreas Ericsson, rdiezmail-temp2, Thomas Rast, in-git-vger,
Michael J Gruber, Jonathan Nieder, Hilco Wijbenga, git
In-Reply-To: <86vctm24le.fsf@red.stonehenge.com>
On Wed, Aug 24, 2011 at 15:48, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>
> Andreas> Whatever, really. The fact that pretty much everyone seems to know
> Andreas> what a branch is and how it works in git after a (very) brief intro
> Andreas> to it means it's either right on target or that people are so used to
> Andreas> the fact that branch means something different in every scm that they
> Andreas> don't even bother loading the word with some preconceived notion that
> Andreas> used to be right in cvs.
>
> It does lead to confusion though, and once you *really* understand that
> a branch is a point, not a line, you can do a lot more cool things with
> git, and rebase and stash make a lot more sense.
Indeed. I don't think Andreas is correct in the assertion that
"everyone seems to know what a branch is and how it works in git after
a (very) brief intro". Rather, I think it is just the case that
everyone seems to know how to use the basic public interface for
branches after a (very) brief intro, and that many tasks allow
everyone to get away with having wrongheaded ideas.
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Michael Schubert @ 2011-08-24 16:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <4E551AD0.7050702@drmicha.warpmail.net>
On 08/24/2011 05:37 PM, Michael J Gruber wrote:
> Michael Schubert venit, vidit, dixit 24.08.2011 17:14:
>> On 08/16/2011 05:14 PM, Jeff King wrote:
>>> On Tue, Aug 16, 2011 at 03:37:33PM +0200, Michael J Gruber wrote:
>>>
>>>>> This isn't right. You are assuming that a remote called "foo" will have
>>>>> all of its branches in refs/remotes/foo. That's true under the default
>>>>> configuration, but technically speaking, the remote tracking branches of
>>>>> "foo" are defined by the right-hand side of foo's fetch refspecs.
>>>>
>>>> You are 100% right here, but...
>>>>
>>>>> So I think you want something more like this:
>>>>
>>>> ...the op still might want to filter simply by the remote name.
>>>
>>> That is a perfectly reasonable approach. It just should be called
>>> "--glob" or something, and not "remote". git-tag allows patterns to an
>>> explicit "tag -l", but "-l" is already taken for git-branch.
>>
>> As suggested, I've just called it "--glob" for now.
>
> Well, again, what's the point in replicating
>
> http://permalink.gmane.org/gmane.comp.version-control.git/172228
>
> and how is it different?
While I just haven't seen this,
> As I've mentioned, I've been in the middle of polishing that up. You can
> follow it if you like:
>
> http://repo.or.cz/w/git/mjg.git/shortlog/refs/heads/branch-list-pattern
I thought I just send it out not knowing you're actually into resurrecting
the "patterns-with-branches series".
Thanks.
^ permalink raw reply
* Buggy handling of non-canonical ref names
From: Michael Haggerty @ 2011-08-24 15:49 UTC (permalink / raw)
To: git discussion list
git has inconsistencies (I would say bugs) in how it handles reference
names that are in non-canonical format (e.g., "/foo/bar", "foo///bar",
etc). Some commands work with reference names that are in non-canonical
form, whereas others do not. Sometimes the behavior depends on whether
the reference is loose or packed.
For example "git branch" and "git update-ref" seem to swallow them OK:
$ git update-ref /foo/bar HEAD
$ cat .git/foo/bar
ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd
$ git branch /bar/baz
$ git for-each-ref | grep baz
ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd commit refs/heads/bar/baz
But other commands do not:
$ git rev-parse /foo/bar --
/foo/bar
fatal: ambiguous argument '/foo/bar': unknown revision or path not
in the working tree.
Use '--' to separate paths from revisions
$ git rev-parse foo///bar --
foo///bar
fatal: ambiguous argument 'foo///bar': unknown revision or path not
in the working tree.
Use '--' to separate paths from revisions
$ git rev-parse foo/bar --
ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd
--
It seems like most of the canonicalization of reference names is via
path canonicalization using the likes of git_snpath() and git_path(),
with the exception of "git check-ref-format --print", which does the
work using its own code. But packed references are not transformed into
paths, so they don't handle canonicalization at all. For example, in
the following case, there is a difference between how packed and
unpacked references are handled:
$ git update-ref refs/heads/foo/bar HEAD
$ git update-ref -d refs/heads/foo///bar HEAD
[Reference was really deleted]
$ git update-ref refs/heads/foo/bar HEAD
$ git pack-refs --all
$ git update-ref -d refs/heads/foo///bar HEAD
error: unable to resolve reference refs/heads/foo///bar: No such
file or directory
$ git for-each-ref | grep foo
ffae1b1dc75896bd89ff3cbe7037f40474e57e2a commit refs/heads/foo/bar
[Reference was not deleted]
What is the policy about reference names and their canonicalization? In
what situations should one be able to use non-canonical refnames, and in
what situations should it be forbidden?
Given that refnames are closely associated with filesystem paths, it is
important that every code path either canonicalize or reject
non-canonical refnames (i.e., failure to do so could be a security
problem). In the absence of clear rules, it will be very difficult to
ensure that this is being done consistently.
I also noticed that check_ref_format() accepts ref names that start with
a "/", but that the leading slash is *not* stripped off as part of the
canonicalization:
$ git check-ref-format /foo/bar ; echo $?
0
$ git check-ref-format --print /foo/bar
/foo/bar
However, creating a reference with such a name is equivalent to creating
a reference without the leading slash:
$ git update-ref /foo/bar HEAD
$ cat .git/foo/bar
ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd
$ git branch /bar/baz
$ git for-each-ref | grep baz
ef6cf90ba11dd6205f8b974692d795ea0b1c0bdd commit refs/heads/bar/baz
Therefore, it seems to belong in the equivalence class of "foo/bar".
The test suite for "git check-ref-format" says nothing about how leading
slashes should be handled.
Either leading slashes should not be allowed in ref names at all or they
should be canonicalized away.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Randal L. Schwartz @ 2011-08-24 15:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Michael Witten, rdiezmail-temp2, Thomas Rast, in-git-vger,
Michael J Gruber, Jonathan Nieder, Hilco Wijbenga, git
In-Reply-To: <4E551BC3.8080701@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> Whatever, really. The fact that pretty much everyone seems to know
Andreas> what a branch is and how it works in git after a (very) brief intro
Andreas> to it means it's either right on target or that people are so used to
Andreas> the fact that branch means something different in every scm that they
Andreas> don't even bother loading the word with some preconceived notion that
Andreas> used to be right in cvs.
It does lead to confusion though, and once you *really* understand that
a branch is a point, not a line, you can do a lot more cool things with
git, and rebase and stash make a lot more sense.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Andreas Ericsson @ 2011-08-24 15:41 UTC (permalink / raw)
To: Michael Witten
Cc: rdiezmail-temp2, Thomas Rast, in-git-vger, Michael J Gruber,
Jonathan Nieder, Hilco Wijbenga, git
In-Reply-To: <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
On 08/23/2011 05:54 PM, Michael Witten wrote:
> On Mon, Aug 22, 2011 at 15:18, R. Diez<rdiezmail-temp2@yahoo.de> wrote:
>>> The main problem is that your request is not very
>>> well-defined: in
>>> nonlinear history there will in general be more than one
>>> commit at the
>>> time requested.
>>>
>>> ---a----b----c----M---- (M is a merge)
>>> \ /
>>> d-----e----f
>>>
>>> ^----April 1st
>>>
>>> Suppose you ask git for "the newest commit as of April 1st"
>>> in this history. Is it supposed to give you b or d?
>>
>> I still don't quite understand how git works, but let me
>> risk a naive statement here. If "a-b-c-M" were 'master',
>> and "d-e-f" were 'new-feature', then on April 1st the
>> current version on 'master' is 'b', because I merged the
>> 'new-feature' branch at a later point in time. Does that
>> make sense?
>
> O! for the love all that is Holy!
>
> You see, guys? The term `branch' was a TERRIBLE choice.
>
> What git calls `branch master' in your example is just a pointer to
> the commit object `M'; it has nothing to do with particular lineages
> like `a-b-c-M'.
>
Back in 2005 when git was young and fresh, there was a discussion about
what to call things. If memory serves (which it might not), I think
the consensus was that "branch" works just fine, and when someone who
doesn't like it comes along we can just tell them that it's short for
"tip-of-branch pointer", which is far more accurate. A "ref" is always
local though, which is why the reflog (which is used for such date
resolving problems) is never even considered to work on remote refs.
They *can* work on remotes' refs though, which is a slightly different
thing.
Whatever, really. The fact that pretty much everyone seems to know
what a branch is and how it works in git after a (very) brief intro
to it means it's either right on target or that people are so used to
the fact that branch means something different in every scm that they
don't even bother loading the word with some preconceived notion that
used to be right in cvs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Michael J Gruber @ 2011-08-24 15:37 UTC (permalink / raw)
To: Michael Schubert; +Cc: Jeff King, git
In-Reply-To: <4E551548.9090807@elegosoft.com>
Michael Schubert venit, vidit, dixit 24.08.2011 17:14:
> On 08/16/2011 05:14 PM, Jeff King wrote:
>> On Tue, Aug 16, 2011 at 03:37:33PM +0200, Michael J Gruber wrote:
>>
>>>> This isn't right. You are assuming that a remote called "foo" will have
>>>> all of its branches in refs/remotes/foo. That's true under the default
>>>> configuration, but technically speaking, the remote tracking branches of
>>>> "foo" are defined by the right-hand side of foo's fetch refspecs.
>>>
>>> You are 100% right here, but...
>>>
>>>> So I think you want something more like this:
>>>
>>> ...the op still might want to filter simply by the remote name.
>>
>> That is a perfectly reasonable approach. It just should be called
>> "--glob" or something, and not "remote". git-tag allows patterns to an
>> explicit "tag -l", but "-l" is already taken for git-branch.
>
> As suggested, I've just called it "--glob" for now.
Well, again, what's the point in replicating
http://permalink.gmane.org/gmane.comp.version-control.git/172228
and how is it different?
As I've mentioned, I've been in the middle of polishing that up. You can
follow it if you like:
http://repo.or.cz/w/git/mjg.git/shortlog/refs/heads/branch-list-pattern
Also, again: git branch is much more like git tag than it is like git
log, so I think the pattern matching options should be, too.
Michael
^ permalink raw reply
* Re: Problem with S_IFGITLINK
From: Adam Kłobukowski @ 2011-08-24 15:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E550E03.3080104@drmicha.warpmail.net>
W dniu 24.08.2011 16:43, Michael J Gruber pisze:
> Adam Kłobukowski venit, vidit, dixit 24.08.2011 14:49:
>> Hello
>>
>> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
>> anyone? :)) and I encountered problem with S_IFGITLINK.
>>
>> Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build
>> in entry.c write_entry.
>>
>> Should I report a bug? (where?, I could not find any reference to
>> bugtracker on git pages)
>
> Yes. Here.
>
> A short log of the build break would be nice.
>
>> Can I fix it somehow? Can I change value of S_IFGITLINK to something else?
>
> From git's cache.h:
>
> /*
> * A "directory link" is a link to another git directory.
> *
> * The value 0160000 is not normally a valid mode, and
> * also just happens to be S_IFDIR + S_IFLNK
> *
> * NOTE! We *really* shouldn't depend on the S_IFxxx macros
> * always having the same values everywhere. We should use
> * our internal git values for these things, and then we can
> * translate that to the OS-specific value. It just so
> * happens that everybody shares the same bit representation
> * in the UNIX world (and apparently wider too..)
> */
>
> Time to implement that translation :|
I may try to implement it, but I my knowledge of Git internals is equal
to zero. If someone can point me what has to be done - I'll be gratefull.
AdamK
^ permalink raw reply
* Re: Problem with S_IFGITLINK
From: Adam Kłobukowski @ 2011-08-24 15:26 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4E55115D.9000909@elegosoft.com>
W dniu 24.08.2011 16:57, Michael Schubert pisze:
> On 08/24/2011 02:49 PM, Adam Kłobukowski wrote:
>> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
>> anyone? :)) [...]
>
> Out of interest: just for fun?
Hobby. There are still active developers and users, but they're 'ugly
and stupid' ;) (I mean: using CVS) for FreeMiNT kernel development. I
would like to propose to switch ti GIT, but I need to be able to compile
native binary first.
AdamK
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Michael Schubert @ 2011-08-24 15:14 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20110816151448.GA5152@sigill.intra.peff.net>
On 08/16/2011 05:14 PM, Jeff King wrote:
> On Tue, Aug 16, 2011 at 03:37:33PM +0200, Michael J Gruber wrote:
>
>>> This isn't right. You are assuming that a remote called "foo" will have
>>> all of its branches in refs/remotes/foo. That's true under the default
>>> configuration, but technically speaking, the remote tracking branches of
>>> "foo" are defined by the right-hand side of foo's fetch refspecs.
>>
>> You are 100% right here, but...
>>
>>> So I think you want something more like this:
>>
>> ...the op still might want to filter simply by the remote name.
>
> That is a perfectly reasonable approach. It just should be called
> "--glob" or something, and not "remote". git-tag allows patterns to an
> explicit "tag -l", but "-l" is already taken for git-branch.
As suggested, I've just called it "--glob" for now.
--- 8< ---
Subject: [PATCH] branch: add option "glob" to filter listed branches
When calling "git branch" with either "-r" or "-a", there is no way to
further limit the output. Add an option "--glob=<pattern>" to allow
limiting the output to matching branch names.
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
Documentation/git-branch.txt | 8 ++++++--
builtin/branch.c | 13 ++++++++++---
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index c50f189..5de3c79 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -8,7 +8,7 @@ git-branch - List, create, or delete branches
SYNOPSIS
--------
[verse]
-'git branch' [--color[=<when>] | --no-color] [-r | -a]
+'git branch' [--color[=<when>] | --no-color] [(-r | -a) [--glob=<pattern>]]
[-v [--abbrev=<length> | --no-abbrev]]
[(--merged | --no-merged | --contains) [<commit>]]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
@@ -20,7 +20,8 @@ DESCRIPTION
With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both.
+branches to be listed, option `-a` shows both and `--glob` limits the
+output to branches matching <pattern>.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -105,6 +106,9 @@ OPTIONS
-a::
List both remote-tracking branches and local branches.
+--glob=<pattern>::
+ List only branches matching pattern.
+
-v::
--verbose::
Show sha1 and commit subject line for each head, along with
diff --git a/builtin/branch.c b/builtin/branch.c
index 3142daa..74730ad 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -17,7 +17,7 @@
#include "revision.h"
static const char * const builtin_branch_usage[] = {
- "git branch [options] [-r | -a] [--merged | --no-merged]",
+ "git branch [options] [(-r | -a) [--glob=<pattern>]] [--merged | --no-merged]",
"git branch [options] [-l] [-f] <branchname> [<start-point>]",
"git branch [options] [-r] (-d | -D) <branchname>...",
"git branch [options] (-m | -M) [<oldbranch>] <newbranch>",
@@ -260,6 +260,7 @@ static char *resolve_symref(const char *src, const char *prefix)
struct append_ref_cb {
struct ref_list *ref_list;
+ const char *glob;
int ret;
};
@@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
+ if (cb->glob && fnmatch(cb->glob, refname, 0))
+ return 0;
+
commit = NULL;
if (ref_list->verbose || ref_list->with_commit || merge_filter != NO_FILTER) {
commit = lookup_commit_reference_gently(sha1, 1);
@@ -492,7 +496,7 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char *glob)
{
int i;
struct append_ref_cb cb;
@@ -506,6 +510,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
cb.ref_list = &ref_list;
+ cb.glob = glob;
cb.ret = 0;
for_each_rawref(append_ref, &cb);
if (merge_filter != NO_FILTER) {
@@ -618,6 +623,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
+ char *glob = NULL;
struct option options[] = {
OPT_GROUP("Generic options"),
@@ -647,6 +653,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_GROUP("Specific git-branch actions:"),
OPT_SET_INT('a', NULL, &kinds, "list both remote-tracking and local branches",
REF_REMOTE_BRANCH | REF_LOCAL_BRANCH),
+ OPT_STRING(0, "glob", &glob, "pattern", "list only branches matching the pattern"),
OPT_BIT('d', NULL, &delete, "delete fully merged branch", 1),
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
@@ -699,7 +706,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (argc == 0)
- return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
+ return print_ref_list(kinds, detached, verbose, abbrev, with_commit, glob);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
--
1.7.6.577.g8d918.dirty
^ permalink raw reply related
* Re: Problem with S_IFGITLINK
From: Michael Schubert @ 2011-08-24 14:57 UTC (permalink / raw)
To: Adam Kłobukowski; +Cc: git
In-Reply-To: <4E54F364.7000503@gmail.com>
On 08/24/2011 02:49 PM, Adam Kłobukowski wrote:
> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
> anyone? :)) [...]
Out of interest: just for fun?
^ permalink raw reply
* Re: Problem with S_IFGITLINK
From: Michael J Gruber @ 2011-08-24 14:43 UTC (permalink / raw)
To: Adam Kłobukowski; +Cc: git
In-Reply-To: <4E54F364.7000503@gmail.com>
Adam Kłobukowski venit, vidit, dixit 24.08.2011 14:49:
> Hello
>
> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
> anyone? :)) and I encountered problem with S_IFGITLINK.
>
> Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build
> in entry.c write_entry.
>
> Should I report a bug? (where?, I could not find any reference to
> bugtracker on git pages)
Yes. Here.
A short log of the build break would be nice.
> Can I fix it somehow? Can I change value of S_IFGITLINK to something else?
From git's cache.h:
/*
* A "directory link" is a link to another git directory.
*
* The value 0160000 is not normally a valid mode, and
* also just happens to be S_IFDIR + S_IFLNK
*
* NOTE! We *really* shouldn't depend on the S_IFxxx macros
* always having the same values everywhere. We should use
* our internal git values for these things, and then we can
* translate that to the OS-specific value. It just so
* happens that everybody shares the same bit representation
* in the UNIX world (and apparently wider too..)
*/
Time to implement that translation :|
Michael
^ permalink raw reply
* Re: Behaviour of git apply --directory
From: Andrew Berry @ 2011-08-24 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfwktwbbb.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]
Thanks for your detailed explanation.
On 2011-08-22, at 2:28 PM, Junio C Hamano wrote:
> Because the patch application in git is always relative to the top level
> of your working tree no matter where you are, this applies to the path you
> intended it to.
This is where I see the issue. For some reason when I specify --directory, I do have to be somewhere in the directory tree that the patch is going to be applied to. For example, in the following it works if my cwd is the repository root, or src, but not patches.
$ find . -not -path '*.git*'
.
./patches
./patches/LICENSE.patch
./src
./src/LICENSE.txt
$ git status
# On branch master
nothing to commit (working directory clean)
$ cat patches/LICENSE.patch
diff --git a/LICENSE.txt b/LICENSE.txt
index 2c095c8..64ee213 100644
--- a/LICENSE.txt
+++ b/LICENSE.txt
@@ -1,3 +1,4 @@
+GPL GPL GPL
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
$ cd patches
$ git apply -v --directory=src LICENSE.patch
$ git status
# On branch master
nothing to commit (working directory clean)
$ cd ..
$ git apply -v --directory=src patches/LICENSE.patch
Checking patch src/LICENSE.txt...
Applied patch src/LICENSE.txt cleanly.
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/LICENSE.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout src
$ cd src
$ git apply -v --directory=src ../patches/LICENSE.patch
Checking patch src/LICENSE.txt...
Applied patch src/LICENSE.txt cleanly.
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: LICENSE.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2488 bytes --]
^ permalink raw reply related
* [PATCH] rebase -i: clean error message for --continue after failed exec
From: Matthieu Moy @ 2011-08-24 14:01 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpqk4a3rkwb.fsf@bauges.imag.fr>
If after a failed "exec" instruction there are staged changes, before
this patch, rebase --continue fails with this message, which is obviously
wrong:
.../git-rebase--interactive: line 774: .../.git/rebase-merge/author-script: No such file or directory
We could try auto-amending HEAD, but this goes against the logic of
.git/rebase-merge/author-script (see also the testcase 'auto-amend only
edited commits after "edit"' in t3404-rebase-interactive.sh) to
auto-amend something the user hasn't explicitely asked to edit.
Instead of doing anything automatically, detect the situation and give a
clean error message. While we're there, also clarify the error message in
case '. "$author_script"' fails, which now corresponds to really weird
senario where the author script exists but can't be read.
Test-case-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Here's my attempt at a patch. After noticing the existance of a test
'auto-amend only edited commits after "edit"', I'm convinced that
auto-amending is not the right thing here.
git-rebase--interactive.sh | 18 +++++++++++++++++-
t/t3404-rebase-interactive.sh | 14 ++++++++++++++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c6ba7c1..5c94506 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -647,8 +647,24 @@ continue)
then
: Nothing to commit -- skip this
else
+ if ! test -f "$author_script"
+ then
+ die "You have staged changes in your working tree. If these changes are meant to be
+squashed into the previous commit, run:
+
+ git commit --amend
+
+If they are meant to go into a new commit, run:
+
+ git commit
+
+In both case, once you're done, continue with:
+
+ git rebase --continue
+"
+ fi
. "$author_script" ||
- die "Cannot find the author identity"
+ die "Error trying to find the author identity to amend commit"
current_head=
if test -f "$amend"
then
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 8538813..b981572 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -527,6 +527,20 @@ test_expect_success 'auto-amend only edited commits after "edit"' '
git rebase --abort
'
+test_expect_success 'clean error after failed "exec"' '
+ test_tick &&
+ test_when_finished "git rebase --abort || :" &&
+ (
+ FAKE_LINES="1 exec_false" &&
+ export FAKE_LINES &&
+ test_must_fail git rebase -i HEAD^
+ ) &&
+ echo "edited again" > file7 &&
+ git add file7 &&
+ test_must_fail git rebase --continue 2>error &&
+ grep "You have staged changes in your working tree." error
+'
+
test_expect_success 'rebase a detached HEAD' '
grandparent=$(git rev-parse HEAD~2) &&
git checkout $(git rev-parse HEAD) &&
--
1.7.6.580.gc2862.dirty
^ permalink raw reply related
* [PATCH] submodule: Demonstrate known breakage during recursive merge
From: Brad King @ 2011-08-24 13:59 UTC (permalink / raw)
To: git, gitster; +Cc: Heiko Voigt
Since commit 68d03e4a (Implement automatic fast-forward merge for
submodules, 2010-07-07) we try to suggest submodule commits that resolve
a conflict. Consider a true recursive merge case
b---bc
/ \ /
o X
\ / \
c---cb
in which the two heads themselves (bc,cb) had resolved a submodule
conflict (i.e. reference different commits than their parents). The
submodule merge search runs during the temporary merge of the two merge
bases (b,c) and prints out a suggestion that is not meaningful to the
user. Then during the main merge the submodule merge search runs again
but dies with the message
fatal: --ancestry-path given but there are no bottom commits
while trying to enumerate candidates. Demonstrate this known breakage
with a new test in t7405-submodule-merge covering the case.
Signed-off-by: Brad King <brad.king@kitware.com>
---
Hi folks,
A co-worker encountered this problem last week in a real project.
The merge dies and does not leave the submodule conflict in the index.
We were able to work around it by moving the submodule out of the way
and resolving the conflict by hand. Then I ran the merge again to
debug the problem and narrowed it down to this case.
BTW, if one adds the line
rm -rf sub && mkdir sub &&
just above the line
test_must_fail git merge top-bc
then the test passes because no submodule merge search runs. Therefore
this test can be switched to expect success when the problem is fixed.
Brad
t/t7405-submodule-merge.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index a8fb30b..8f6f2d6 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge.sh
@@ -228,4 +228,55 @@ test_expect_success 'merging with a modify/modify conflict between merge bases'
git merge d
'
+# canonical criss-cross history in top and submodule
+test_expect_success 'setup for recursive merge with submodule' '
+ mkdir merge-recursive &&
+ (cd merge-recursive &&
+ git init &&
+ mkdir sub &&
+ (cd sub &&
+ git init &&
+ test_commit a &&
+ git checkout -b sub-b master &&
+ test_commit b &&
+ git checkout -b sub-c master &&
+ test_commit c &&
+ git checkout -b sub-bc sub-b &&
+ git merge sub-c &&
+ git checkout -b sub-cb sub-c &&
+ git merge sub-b &&
+ git checkout master) &&
+ git add sub &&
+ git commit -m a &&
+ git checkout -b top-b master &&
+ (cd sub && git checkout sub-b) &&
+ git add sub &&
+ git commit -m b &&
+ git checkout -b top-c master &&
+ (cd sub && git checkout sub-c) &&
+ git add sub &&
+ git commit -m c &&
+ git checkout -b top-bc top-b &&
+ git merge -s ours -n top-c &&
+ (cd sub && git checkout sub-bc) &&
+ git add sub &&
+ git commit -m bc &&
+ git checkout -b top-cb top-c &&
+ git merge -s ours -n top-b &&
+ (cd sub && git checkout sub-cb) &&
+ git add sub &&
+ git commit -m cb)
+'
+
+# merge should leave submodule unmerged in index
+test_expect_failure 'recursive merge with submodule' '
+ (cd merge-recursive &&
+ test_must_fail git merge top-bc &&
+ echo "160000 $(git rev-parse top-cb:sub) 2 sub" > expect2 &&
+ echo "160000 $(git rev-parse top-bc:sub) 3 sub" > expect3 &&
+ git ls-files -u > actual &&
+ grep "$(cat expect2)" actual > /dev/null &&
+ grep "$(cat expect3)" actual > /dev/null)
+'
+
test_done
--
1.7.4.4
^ permalink raw reply related
* Re: rebase -i: Should --continue auto-amend after failed exec?
From: Matthieu Moy @ 2011-08-24 13:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git@vger.kernel.org List
In-Reply-To: <4E40511B.7090206@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> If after a failed "exec" instruction there are staged changes, then currently rebase
> --continue fails with:
>
> .../git-rebase--interactive: line 774: .../.git/rebase-merge/author-script: No such file or directory
That's obviously bad, there should at least be an accurate error
message.
> But shouldn't this amend the HEAD commit? The documentation is not clear
> (from git-rebase.txt):
>
> The interactive rebase will stop when a command fails (i.e. exits with
> non-0 status) to give you an opportunity to fix the problem. You can
> continue with `git rebase --continue`.
>
> This may be interpreted to work like "edit", and IMO would be a very useful
> modus operandi.
I'm not sure. What happens in "edit" is that when reaching the "edit"
line, git-rebase--interactive.sh calls die_with_patch, which writes
author information in .git/rebase-merge/author-script, which really
means "I've stopped on this commit, this is the one that we should
implicitely amend with --continue".
The case of "exec" is a bit different: you don't stop "on a commit", but
after doing something else. You can hardly guess whether the staged
changes are meant to amend the existing commit, or to make a new one.
Actually, that could even be
pick deadbeef Existing commit
exec foo > bar.txt; git add bar.txt; git commit -m "added during rebase"
exec false
pick c00ffee Another commit
then auto-amending may be really confusing: should it amend the HEAD
commit that you've just created (this would really go against the logic
of .git/rebase-merge/author-script) or the last picked commit (which you
can't really do since it's not HEAD)?
I think it's best to abort, with an accurate error message pointing the
user to both solutions (commit --amend && rebase --continue or commit &&
rebase --continue). I'll try a patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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