* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-26 4:09 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jeff King, Jay Soffian, git discussion list, Jakub Narebski
In-Reply-To: <4E7DB916.6010606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 09/24/2011 08:15 AM, Jeff King wrote:
> For most software projects, the user does
>
> git pull
> make
>
> daily. There is nothing that a nasty .gitconfig can do that can't be
> done more easily by a nasty Makefile (or anything else in the build
> process). The moment I pull from Junio's repository and run a build
> without having personally done a full code review first, I've given
> Junio complete pownership of my account.
I suspect that argument is somewhat leaky.
Will I be the _only_ one you will be pulling from? What if I were not so
careful and relay a contaminated in-tree configuration file (which I would
never use myself) to trusting downstream users like you?
>> I'm not sure it makes sense to have it in the tree at all. For
>> attributes it makes sense, because you are annotating a path at a
>> _specific_ revision. But config is often much more meta- than that.
>> Take textconv for an example. The gitattributes say "foo.pdf should use
>> the 'pdf' diff driver". That makes sense to go in a revision. But the
>> config will say "pdf files can be converted to text using
>> /usr/bin/pdftotext". That is not something that is tied to the revision
>> at all, and should exist outside of any revision. I.e., whether I am
>> doing a "git show" on the HEAD, or on some ancient commit, I would want
>> to use the same value, not whatever tool I used to convert PDFs years
>> ago.
I agree 100% with Peff on this point. What pdfviewer is configured to be
used for my repository is tied closely to what I happen to have installed
on my box that I use that repository on. This is not by accident but by
design why attributes only specify what _kind_ of payload is in the path,
and leave it up to the config to say _how_ to handle each kind of payload
on the box).
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-26 1:42 UTC (permalink / raw)
To: git
In-Reply-To: <CAH5451nk9FnqwhEe0SWxDc3TnLiTLnFgD6zB3jDehFZn6=qWvw@mail.gmail.com>
Andrew Ardill wrote:
> As any commits you make in a detached state are in the reflog until
> they expire (by default 30 days I think?) you have more than enough
> time to decide if you want to keep the work - which you can do very
> easily by assigning it a name. If the default time is not long enough,
> simply extend it in your config
> git config gc.reflogExpire = 10000 years <- syntax might not be correct
Thanks for your post, but, again, my point is that Git does not support
anonymous branching as part of a normal workflow. Having X days until
detonation is hardly part of a normal workflow (even if X can be changed,
as you suggest).
Anyway, this thread's really going off topic, so I'll try not to reply
again.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Andrew Ardill @ 2011-09-26 1:34 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1aec7c1qq0n56.sxybjnsj6ngr$.dlg@40tude.net>
On 26 September 2011 10:56, tactical <a5158017@nepwk.com> wrote:
> Konstantin Khomoutov wrote:
>
>>>>> From what I read, detached heads are subject to garbage collection.
>>>>
>>>> No, HEAD is protected against garbage collecting. To be sure you
>>>> should name a branch when switching branches, though reflog would
>>>> protect you for 30 days (by default) even if you don't do that.
>>>
>>> So Git doesn't really support anonymous branching as part of a normal
>>> workflow.
>>
>> I perceive a certain logical fallacy here: you cannot switch between
>> anything anonymous because to switch, you should somehow identify
>> something to switch to--a name in whatever sense we put into this word.
>
> In Mercurial, you can just update to a particular changeset (and you
> identify that changeset by repository-local revision number or globally
> unique ID) and then commit again. The point is that there's no need to
> give a label to a head in Mercurial (although you can if you want to, using
> Mercurial bookmarks, which are basically the same as what Git uses).
>
> Here's an example of anonymous branching:
>
> c:\test>hg init
>
> c:\test>echo test>foo
>
> c:\test>hg commit --addremove -m initial
> adding foo
>
> c:\test>echo first>>foo
>
> c:\test>hg commit -m first
>
> c:\test>hg log
> changeset: 1:3e895ec28d6c
> tag: tip
> user: tactical
> date: Mon Sep 26 01:39:46 2011 +0100
> summary: first
>
> changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> c:\test>hg update 0
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> c:\test>echo second>>foo
>
> c:\test>hg commit -m second
> created new head
>
> c:\test>hg glog
> @ changeset: 2:35c82a7e7de1
> | tag: tip
> | parent: 0:b51644bb3450
> | user: tactical
> | date: Mon Sep 26 01:40:10 2011 +0100
> | summary: second
> |
> | o changeset: 1:3e895ec28d6c
> |/ user: tactical
> | date: Mon Sep 26 01:39:46 2011 +0100
> | summary: first
> |
> o changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> I now have two anonymous branches, and these will never be garbage
> collected. I can easily update to either branch with "hg update 1" or "hg
> update 2" (or "hg update 0" again, if i want to create yet another
> anonymous branch).
>
>> As I understand, by switching between branches in Mercurial you mean
>> switching between directories with clones;
>
> No. Clones are a different topic.
>
>> As to branches, they do have names in Git but they are very loosely
>> coupled with their names: tag a tip of some branch (to still have a
>> handle on that tip commit) then delete that branch--there will be no
>> traces of that branch's name left, the branch's name is not encoded in
>> its history in any way.
>
> Git branch names are basically the same as Mercurial bookmarks. The
> difference is that in Mercurial you don't *have* to use bookmarks.
>
>> The branch names is just a way to not mess with
>> SHA-1 names of commits (and to have references to those commits to keep
>> them out of consideration for garbage collection).
>> Hence the idea to demand support for anonymous branches in Git's model
>> is just unfounded.
>
> I think it's simply a weakness of Git. There are zero problems with
> anonymous branching in Mercurial, and it's a very powerful and simple
> system.
>
I am no expert on this, however git can (of course) do 'anonymous
branching' just as simply as mercurial, with one caveat; for most
intents and purposes (as far as I have seen/heard discussed) git and
mercurial are homomorphic, and in the situations they are not git is
the more general system.
The flow that you are using for anonymous branching in mercurial is
easily reproducible in git, using detached heads. Checkout a revision
(note: not a ref)
git checkout HEAD@{1}
hack + commit. Repeat as often as you like. Your concern is that these
will (eventually) be garbage collected. Again, I am not an expert in
this so please correct me if I have this incorrect, but the man page
for gc says:
git-gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current
set of branches and tags, but also objects referenced by the index,
remote tracking branches, refs saved by git-filter-branch in
refs/original/, or reflogs (which may references commits in branches
that were later amended or rewound).
As any commits you make in a detached state are in the reflog until
they expire (by default 30 days I think?) you have more than enough
time to decide if you want to keep the work - which you can do very
easily by assigning it a name. If the default time is not long enough,
simply extend it in your config
git config gc.reflogExpire = 10000 years <- syntax might not be correct
The reason this is not true by default is that _most_ people don't
work exclusively in anonymous branches, and it is far nicer
performance wise to have git clean up for you.
So you don't *have* to use branches in git - they just make it much
easier to get around. They cost practically nothing to use, so I don't
really understand why you wouldn't want to for anything other than
just a quick throwaway test or scratch idea.
I hope that clears it up a little.
Andrew
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-26 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <20110926003447.GG10955@localhost.localdomain>
Konstantin Khomoutov wrote:
>>>> From what I read, detached heads are subject to garbage collection.
>>>
>>> No, HEAD is protected against garbage collecting. To be sure you
>>> should name a branch when switching branches, though reflog would
>>> protect you for 30 days (by default) even if you don't do that.
>>
>> So Git doesn't really support anonymous branching as part of a normal
>> workflow.
>
> I perceive a certain logical fallacy here: you cannot switch between
> anything anonymous because to switch, you should somehow identify
> something to switch to--a name in whatever sense we put into this word.
In Mercurial, you can just update to a particular changeset (and you
identify that changeset by repository-local revision number or globally
unique ID) and then commit again. The point is that there's no need to
give a label to a head in Mercurial (although you can if you want to, using
Mercurial bookmarks, which are basically the same as what Git uses).
Here's an example of anonymous branching:
c:\test>hg init
c:\test>echo test>foo
c:\test>hg commit --addremove -m initial
adding foo
c:\test>echo first>>foo
c:\test>hg commit -m first
c:\test>hg log
changeset: 1:3e895ec28d6c
tag: tip
user: tactical
date: Mon Sep 26 01:39:46 2011 +0100
summary: first
changeset: 0:b51644bb3450
user: tactical
date: Mon Sep 26 01:39:40 2011 +0100
summary: initial
c:\test>hg update 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
c:\test>echo second>>foo
c:\test>hg commit -m second
created new head
c:\test>hg glog
@ changeset: 2:35c82a7e7de1
| tag: tip
| parent: 0:b51644bb3450
| user: tactical
| date: Mon Sep 26 01:40:10 2011 +0100
| summary: second
|
| o changeset: 1:3e895ec28d6c
|/ user: tactical
| date: Mon Sep 26 01:39:46 2011 +0100
| summary: first
|
o changeset: 0:b51644bb3450
user: tactical
date: Mon Sep 26 01:39:40 2011 +0100
summary: initial
I now have two anonymous branches, and these will never be garbage
collected. I can easily update to either branch with "hg update 1" or "hg
update 2" (or "hg update 0" again, if i want to create yet another
anonymous branch).
> As I understand, by switching between branches in Mercurial you mean
> switching between directories with clones;
No. Clones are a different topic.
> As to branches, they do have names in Git but they are very loosely
> coupled with their names: tag a tip of some branch (to still have a
> handle on that tip commit) then delete that branch--there will be no
> traces of that branch's name left, the branch's name is not encoded in
> its history in any way.
Git branch names are basically the same as Mercurial bookmarks. The
difference is that in Mercurial you don't *have* to use bookmarks.
> The branch names is just a way to not mess with
> SHA-1 names of commits (and to have references to those commits to keep
> them out of consideration for garbage collection).
> Hence the idea to demand support for anonymous branches in Git's model
> is just unfounded.
I think it's simply a weakness of Git. There are zero problems with
anonymous branching in Mercurial, and it's a very powerful and simple
system.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Konstantin Khomoutov @ 2011-09-26 0:34 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1ttmqsxtaj98i$.hv6s5shjeugr.dlg@40tude.net>
On Sun, Sep 25, 2011 at 10:07:24PM +0100, tactical wrote:
[...]
> > I think you can use detached HEAD for that, at least when working on
> > one issue at a time (you have to name branch when switching to some
> > other work).
>
> But in Mercurial I can switch between anonymous branches as much as I like
> without anything ever being deleted.
>
> >> From what I read, detached heads are subject to garbage collection.
> >
> > No, HEAD is protected against garbage collecting. To be sure you
> > should name a branch when switching branches, though reflog would
> > protect you for 30 days (by default) even if you don't do that.
>
> So Git doesn't really support anonymous branching as part of a normal
> workflow.
I perceive a certain logical fallacy here: you cannot switch between
anything anonymous because to switch, you should somehow identify
something to switch to--a name in whatever sense we put into this word.
As I understand, by switching between branches in Mercurial you mean
switching between directories with clones; if so, you had had to name
those directories when they were created.
As to branches, they do have names in Git but they are very loosely
coupled with their names: tag a tip of some branch (to still have a
handle on that tip commit) then delete that branch--there will be no
traces of that branch's name left, the branch's name is not encoded in
its history in any way. The branch names is just a way to not mess with
SHA-1 names of commits (and to have references to those commits to keep
them out of consideration for garbage collection).
Hence the idea to demand support for anonymous branches in Git's model
is just unfounded.
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-25 21:07 UTC (permalink / raw)
To: git
In-Reply-To: <m3oby8pcfz.fsf@localhost.localdomain>
Jakub Narebski wrote:
>>> With merging into branch with uncomitted changes your fairly well
>>> understood 3-way merge (sometimes virtual 3-way merge in the case of
>>> multiple common ancestors) would turn into 4-way merge.
>>
>> I don't see why it would be a four-way merge rather than a three-way merge.
>
> You have four version: "base" (ancestor version), "theirs"
> (branch/clone being merged), "ours" (comitted changes on current
> branch) and "new" (uncomitted changes on current branch).
>
> Unless Mercurial does 3-way merge of "new", "theirs" and "base"...
> with transaction based atomicity (saving "new" before attempting
> merge) they can do that.
I've not read the code, but surely Mercurial does a three-way merge here.
It wouldn't be sane to do anything else.
>>> What you use uncomitted changes for, I would use is a separate branch,
>>> and keep it rebasing (something like using 'mq' in Mercurial).
>>
>> Yes, but, as I mentioned, rebasing is less flexible. A rebase here is
>> effectively a merge and a commit in one step, whereas my approach separates
>> the merge and the commit.
>
> Errr... what? You first commit your changes, then keep it rebasing to
> keep them up to date on top of fresh version.
Like I said before, with my approach, after I merge, I can check that
everything still compiles, that unit tests still pass, and so on, before
finally checking in. Rebasing, on the other hand, is essentially merging
and checking in in one step. *After* you've rebased, you can run unit
tests, etc., but you've *already* checked in at that point. (Sure, you
could then mutate history if need be, but it's rather less flexible than my
approach, where the check-in is not made until desired.)
>>> What do you use anonymous branching for?
>>
>> Anonymous branching is great for minor divergence that isn't really
>> significant enough to deserve a name. It's also great for branches that
>> *are* significant enough to deserve a name, but where you want to defer
>> naming the branch right up until you merge it into another branch. At that
>> point you can 'name' the branch in the commit message.
>
> I think you can use detached HEAD for that, at least when working on
> one issue at a time (you have to name branch when switching to some
> other work).
But in Mercurial I can switch between anonymous branches as much as I like
without anything ever being deleted.
>> From what I read, detached heads are subject to garbage collection.
>
> No, HEAD is protected against garbage collecting. To be sure you
> should name a branch when switching branches, though reflog would
> protect you for 30 days (by default) even if you don't do that.
So Git doesn't really support anonymous branching as part of a normal
workflow.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-25 20:58 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1rwoliveqwr1v.u3bsx5axtgsb$.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Jakub Narebski wrote:
>
> > With merging into branch with uncomitted changes your fairly well
> > understood 3-way merge (sometimes virtual 3-way merge in the case of
> > multiple common ancestors) would turn into 4-way merge.
>
> I don't see why it would be a four-way merge rather than a three-way merge.
You have four version: "base" (ancestor version), "theirs"
(branch/clone being merged), "ours" (comitted changes on current
branch) and "new" (uncomitted changes on current branch).
Unless Mercurial does 3-way merge of "new", "theirs" and "base"...
with transaction based atomicity (saving "new" before attempting
merge) they can do that.
With Git you have additional complication: the index state.
> > Even if you
> > can automate it somehow (I do wonder how Mercurial manages that),
> > there could be problem resolving conflicts, unless you happen to touch
> > different parts of file.
>
> This behaviour is by design in Mercurial. It's simple, and it works. I've
> never had a problem with resolving conflicts here, and I don't see why I
> ever would.
It if really is 3-way merge, you wouldn't. If it isn't (e.g. it is
3-way merge + applying patch, like merge + stash apply in git), then
there are [nasty] corner cases.
Anyway I hope that Mercurial does test this feature extensively.
[...]
> > What you use uncomitted changes for, I would use is a separate branch,
> > and keep it rebasing (something like using 'mq' in Mercurial).
>
> Yes, but, as I mentioned, rebasing is less flexible. A rebase here is
> effectively a merge and a commit in one step, whereas my approach separates
> the merge and the commit.
Errr... what? You first commit your changes, then keep it rebasing to
keep them up to date on top of fresh version.
> > > Another example of this is the lack of support for anonymous branching as
> > > part of a normal workflow in Git. Anonymous branching is very powerful and
> > > very simple. I use it all the time in Mercurial.
> >
> > What do you use anonymous branching for?
>
> Anonymous branching is great for minor divergence that isn't really
> significant enough to deserve a name. It's also great for branches that
> *are* significant enough to deserve a name, but where you want to defer
> naming the branch right up until you merge it into another branch. At that
> point you can 'name' the branch in the commit message.
I think you can use detached HEAD for that, at least when working on
one issue at a time (you have to name branch when switching to some
other work).
> (Of course, you
> could also create a Mercurial bookmark at that point, and then you'd
> essentially have a "Git branch".)
Except for the fact that AFAIK Mercurial bookmarks have single global
namespace for branch (bookmark) names, while Git uses more flexible
but less newbie-user-friendly branch to remote-tracking branch name
mapping via "refspec".
> > Note that with Git by default pushing "matching" branches, you can
> > create private local-only branches. The have to have _some_ name
> > (even if it is 'foo/temp'), but I think that it makes them perhaps
> > more work to create, but easier to use (to switch branches)... and for
> > single anonymous branch you can always use "detached HEAD".
>
> From what I read, detached heads are subject to garbage collection.
No, HEAD is protected against garbage collecting. To be sure you
should name a branch when switching branches, though reflog would
protect you for 30 days (by default) even if you don't do that.
--
Jakub Narębski
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-25 20:43 UTC (permalink / raw)
To: git; +Cc: Christian Couder
In-Reply-To: <1315529522448-6774328.post@n2.nabble.com>
A coworker of mine pointed out to me that a simple
git checkout
can also take rather long periods of time > 3 mins when run
on a repo with ~100K refs.
While this is not massive like the other problem I reported,
it still seems like it is more than one would expect. So, I
tried an older version of git, and to my surprise/delight,
it was much faster (.2s). So, I bisected this issue also,
and it seems that the "offending" commit is
680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
commit 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07
Author: Christian Couder <chriscool@tuxfamily.org>
Date: Fri Jan 23 10:06:53 2009 +0100
replace_object: add mechanism to replace objects found
in "refs/replace/"
The code implementing this mechanism has been copied
more-or-less
from the commit graft code.
This mechanism is used in "read_sha1_file". sha1 passed
to this
function that match a ref name in "refs/replace/" are
replaced by
the sha1 that has been read in the ref.
We "die" if the replacement recursion depth is too high
or if we
can't read the replacement object.
Signed-off-by: Christian Couder
<chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now, I suspect this commit is desirable, but I was hoping
that perhaps a look at it might inspire someone to find an
obvious problem with it.
Thanks,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-25 20:23 UTC (permalink / raw)
To: git
In-Reply-To: <m31uv4rc47.fsf@localhost.localdomain>
Jakub Narebski wrote:
> With merging into branch with uncomitted changes your fairly well
> understood 3-way merge (sometimes virtual 3-way merge in the case of
> multiple common ancestors) would turn into 4-way merge.
I don't see why it would be a four-way merge rather than a three-way merge.
> Even if you
> can automate it somehow (I do wonder how Mercurial manages that),
> there could be problem resolving conflicts, unless you happen to touch
> different parts of file.
This behaviour is by design in Mercurial. It's simple, and it works. I've
never had a problem with resolving conflicts here, and I don't see why I
ever would.
>> And that, I feel, is a problem with Git. In some cases, you can't do
>> things how you want -- you have to do things how Git wants.
>
> Please take into account the fact that when you were creating your
> workflow to suit your situation you were "forced" to fit it to
> Mercurial abilities and best practices. No wonder that it does not
> fit Git-ish workflows.
No, I came to the distributed world only recently, from Subversion. I
choose to use clones over plain anonymous branching, over bookmarks, and
over named branching because I prefer the approach. I can, of course, do
"Git branching" in Mercurial very easily if I want (with Mercurial
bookmarks).
> What you use uncomitted changes for, I would use is a separate branch,
> and keep it rebasing (something like using 'mq' in Mercurial).
Yes, but, as I mentioned, rebasing is less flexible. A rebase here is
effectively a merge and a commit in one step, whereas my approach separates
the merge and the commit.
>> Another example of this is the lack of support for anonymous branching as
>> part of a normal workflow in Git. Anonymous branching is very powerful and
>> very simple. I use it all the time in Mercurial.
>
> What do you use anonymous branching for?
Anonymous branching is great for minor divergence that isn't really
significant enough to deserve a name. It's also great for branches that
*are* significant enough to deserve a name, but where you want to defer
naming the branch right up until you merge it into another branch. At that
point you can 'name' the branch in the commit message. (Of course, you
could also create a Mercurial bookmark at that point, and then you'd
essentially have a "Git branch".)
> Note that with Git by default pushing "matching" branches, you can
> create private local-only branches. The have to have _some_ name
> (even if it is 'foo/temp'), but I think that it makes them perhaps
> more work to create, but easier to use (to switch branches)... and for
> single anonymous branch you can always use "detached HEAD".
>From what I read, detached heads are subject to garbage collection.
^ permalink raw reply
* Re: Symbolic refs and the git protocol?
From: Ilari Liusvaara @ 2011-09-25 18:50 UTC (permalink / raw)
To: Avi Kivity; +Cc: Git Mailing List
In-Reply-To: <4E7F29EB.8000800@redhat.com>
On Sun, Sep 25, 2011 at 04:17:31PM +0300, Avi Kivity wrote:
>
> Now it looks like kernel.org will no longer offer shell access. Is
> it possible to support symbolic-ref via 'git push'?
AFAIK, no, it isn't.
-Ilari
^ permalink raw reply
* Re: [PATCH] Revert removal of multi-match discard heuristic in 27af01
From: René Scharfe @ 2011-09-25 17:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1316957948-1908-1-git-send-email-rctay89@gmail.com>
Am 25.09.2011 15:39, schrieb Tay Ray Chuan:
> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
>
> 27af01d (xdiff/xprepare: improve O(n*m) performance in
> xdl_cleanup_records(), 2011-08-17) was supposed to be a performance
> boost only. However, it unexpectedly changed the behaviour of diff.
>
> Revert a part of 27af01d that removes logic that mark lines as
> "multi-match" (ie. dis[i] == 2). This was preventing the multi-match
> discard heuristic (performed in xdl_cleanup_records() and
> xdl_clean_mmatch()) from executing.
>
> Reported-by: Alexander Pepper <pepper@inf.fu-berlin.de>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>
> ---
>
> Junio, this replaces the patch the one in the
> 'rs/diff-cleanup-records-fix' topic in 'pu'. The only difference is in
> the patch message.
>
> René, will need your SOB on this. Thanks for working to produce the
> patch. Please disregard my earlier message [1], further reading has
> shown my previous understanding to be wrong.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
>
> [1] <CALUzUxprUFGMR-WVEMOOvYiwkev1cfxHOyBmZq9bKJcHq5E2VA@mail.gmail.com>
> ---
> xdiff/xprepare.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
> index 05a8f01..4c447ca 100644
> --- a/xdiff/xprepare.c
> +++ b/xdiff/xprepare.c
> @@ -398,7 +398,7 @@ static int xdl_clean_mmatch(char const *dis, long i, long s, long e) {
> * might be potentially discarded if they happear in a run of discardable.
> */
> static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xdf2) {
> - long i, nm, nreff;
> + long i, nm, nreff, mlim;
> xrecord_t **recs;
> xdlclass_t *rcrec;
> char *dis, *dis1, *dis2;
> @@ -411,16 +411,20 @@ static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xd
> dis1 = dis;
> dis2 = dis1 + xdf1->nrec + 1;
>
> + if ((mlim = xdl_bogosqrt(xdf1->nrec)) > XDL_MAX_EQLIMIT)
> + mlim = XDL_MAX_EQLIMIT;
> for (i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart]; i <= xdf1->dend; i++, recs++) {
> rcrec = cf->rcrecs[(*recs)->ha];
> nm = rcrec ? rcrec->len2 : 0;
> - dis1[i] = (nm == 0) ? 0: 1;
> + dis1[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
> }
>
> + if ((mlim = xdl_bogosqrt(xdf2->nrec)) > XDL_MAX_EQLIMIT)
> + mlim = XDL_MAX_EQLIMIT;
> for (i = xdf2->dstart, recs = &xdf2->recs[xdf2->dstart]; i <= xdf2->dend; i++, recs++) {
> rcrec = cf->rcrecs[(*recs)->ha];
> nm = rcrec ? rcrec->len1 : 0;
> - dis2[i] = (nm == 0) ? 0: 1;
> + dis2[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
> }
>
> for (nreff = 0, i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart];
^ permalink raw reply
* [PATCH/RFCv2 2/2] run post-receive and post-update hooks with empty stdin/no args for invalid ref deletion
From: Pang Yan Han @ 2011-09-25 17:37 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin
In-Reply-To: <1316927182-14212-3-git-send-email-pangyanhan@gmail.com>
The post-receive and post-update hooks are triggered with invalid input on
stdin and invalid args respectively during the deletion of corrupt or
non-existent refs during a push.
Teach receive-pack to run post-receive hook with empty stdin and post-update
hook with empty args in the event of an invalid ref deletion.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
This has been updated with the suggestions from Sitaram Chamarty, as stated in
http://thread.gmane.org/gmane.comp.version-control.git/182056/focus=182065
builtin/receive-pack.c | 35 +++++++++++++-
t/t5516-fetch-push.sh | 118 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 150 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ae164da..28d0b09 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -153,6 +153,26 @@ struct command {
char ref_name[FLEX_ARRAY]; /* more */
};
+/* For invalid refs */
+static struct command **invalid_delete;
+static size_t invalid_delete_nr;
+static size_t invalid_delete_alloc;
+
+static void invalid_delete_append(struct command *cmd)
+{
+ ALLOC_GROW(invalid_delete, invalid_delete_nr + 1, invalid_delete_alloc);
+ invalid_delete[invalid_delete_nr++] = cmd;
+}
+
+static int is_invalid_delete(struct command *cmd)
+{
+ size_t i;
+ for (i = 0; i < invalid_delete_nr; i++)
+ if (invalid_delete[i] == cmd)
+ return 1;
+ return 0;
+}
+
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
@@ -248,7 +268,8 @@ static int run_receive_hook(struct command *commands, const char *hook_name)
}
for (cmd = commands; cmd; cmd = cmd->next) {
- if (!cmd->error_string) {
+ /* Run with empty stdin for invalid ref deletion */
+ if (!cmd->error_string && !is_invalid_delete(cmd)) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
sha1_to_hex(cmd->old_sha1),
sha1_to_hex(cmd->new_sha1),
@@ -447,6 +468,7 @@ static const char *update(struct command *cmd)
if (!parse_object(old_sha1)) {
rp_warning("Allowing deletion of corrupt ref.");
old_sha1 = NULL;
+ invalid_delete_append(cmd);
}
if (delete_ref(namespaced_name, old_sha1, 0)) {
rp_error("failed to delete %s", name);
@@ -490,8 +512,14 @@ static void run_update_post_hook(struct command *commands)
char *p;
if (cmd->error_string)
continue;
- p = xmalloc(strlen(cmd->ref_name) + 1);
- strcpy(p, cmd->ref_name);
+ if (is_invalid_delete(cmd)) {
+ /* Run with empty args for invalid ref deletion */
+ p = xmalloc(1);
+ p[0] = '\0';
+ } else {
+ p = xmalloc(strlen(cmd->ref_name) + 1);
+ strcpy(p, cmd->ref_name);
+ }
argv[argc] = p;
argc++;
}
@@ -866,5 +894,6 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
}
if (use_sideband)
packet_flush(1);
+ free(invalid_delete);
return 0;
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 3abb290..038a3b3 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -40,6 +40,39 @@ mk_test () {
)
}
+mk_test_with_hooks() {
+ mk_test "$@" &&
+ (
+ cd testrepo &&
+ mkdir .git/hooks &&
+ cd .git/hooks &&
+
+ cat >pre-receive <<'EOF' &&
+#!/bin/sh
+cat - >>pre-receive.actual
+EOF
+
+ cat >update <<'EOF' &&
+#!/bin/sh
+printf "%s %s %s\n" "$@" >>update.actual
+EOF
+ cat >post-receive <<'EOF' &&
+#!/bin/sh
+cat - >>post-receive.actual
+EOF
+
+ cat >post-update <<'EOF' &&
+#!/bin/sh
+for ref in "$@"
+do
+ printf "%s\n" "$ref" >>post-update.actual
+done
+EOF
+
+ chmod u+x pre-receive update post-receive post-update
+ )
+}
+
mk_child() {
rm -rf "$1" &&
git clone testrepo "$1"
@@ -559,6 +592,91 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'pushing valid refs triggers post-receive and post-update hooks' '
+ mk_test_with_hooks heads/master &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ git push testrepo refs/heads/master:refs/heads/master :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting non-existent ref triggers post-receive and post-update hooks with empty args' '
+ mk_test_with_hooks heads/master &&
+ git push testrepo :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting invalid ref triggers post-receive and post-update hooks with empty args' '
+ mk_test_with_hooks heads/master &&
+ rm -f testrepo/.git/objects/??/* &&
+ git push testrepo :refs/heads/master &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/master
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
test_expect_success 'allow deleting a ref using --delete' '
mk_test heads/master &&
(cd testrepo && git config receive.denyDeleteCurrent warn) &&
--
1.7.7.rc3.2.gd706f.dirty
^ permalink raw reply related
* Re: Can a git changeset be created with no parent
From: Carlos Martín Nieto @ 2011-09-25 14:33 UTC (permalink / raw)
To: vra5107; +Cc: git
In-Reply-To: <1316960136073-6829212.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
On Sun, 2011-09-25 at 07:15 -0700, vra5107 wrote:
> Hi
>
> I am currently in the process of converting a large hg repository.
> One of the changesets has no parents assigned. So to mirror that is it
> possible to create a git changeset that doesnot have a parent ?
They're called commits in git, and yes it's possible. They are called
orphan commits and it's what you get when you do the first commit in the
repository.
You can do this with 'git checkout --orphan somebranch'. Notice that the
index will be kept, you'll need to either use 'git rm' or 'git add -A'.
There is a longer explanation in the manpage for 'git checkout'.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Can a git changeset be created with no parent
From: Andreas Ericsson @ 2011-09-25 14:33 UTC (permalink / raw)
To: vra5107; +Cc: git
In-Reply-To: <1316960136073-6829212.post@n2.nabble.com>
On 09/25/2011 04:15 PM, vra5107 wrote:
> Hi
>
> I am currently in the process of converting a large hg repository.
> One of the changesets has no parents assigned. So to mirror that is it
> possible to create a git changeset that doesnot have a parent ?
>
Yes. Each and every project git has ever managed starts with a commit
just like that. In git lingo, it's called a "root commit".
--
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
* Can a git changeset be created with no parent
From: vra5107 @ 2011-09-25 14:15 UTC (permalink / raw)
To: git
Hi
I am currently in the process of converting a large hg repository.
One of the changesets has no parents assigned. So to mirror that is it
possible to create a git changeset that doesnot have a parent ?
Thanks
Venkat
--
View this message in context: http://git.661346.n2.nabble.com/Can-a-git-changeset-be-created-with-no-parent-tp6829212p6829212.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Symbolic refs and the git protocol?
From: Sitaram Chamarty @ 2011-09-25 14:10 UTC (permalink / raw)
To: Avi Kivity; +Cc: Git Mailing List, John Hawley
In-Reply-To: <4E7F313A.2050103@redhat.com>
On Sun, Sep 25, 2011 at 7:18 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/25/2011 04:42 PM, Sitaram Chamarty wrote:
>>
>> On Sun, Sep 25, 2011 at 6:47 PM, Avi Kivity<avi@redhat.com> wrote:
>> > With the old kernel.org setup, practically the only think I needed to
>> > do on
>> > the server itself is the 'git symbolic-ref' command (used to point
>> > refs/heads/linux-next at the correct stream).
>> >
>> > Now it looks like kernel.org will no longer offer shell access. Is it
>> > possible to support symbolic-ref via 'git push'?
>>
>> Can I assume you mean specifically for HEAD, as in 'git symbolic-ref
>> HEAD refs/heads/some-branch'?
>
> No, I use them for ordinary branches, for example
>
> git symbolic-ref refs/heads/linux-next refs/heads/kvm-updates/3.2
>
> from this point on, any update to kvm-updates/3.2 will be reflected in the
> linux-next ref.
>
>> Although gitolite disables shell access by design, it provides several
>> (optionally installed) features to allow specific shell commands to be
>> executed. One such command is "set-head", which does exactly what you
>> ask. You run it like 'ssh git@server set-head reponame.git
>> refs/heads/foo' and it ends up running 'git symbolic-ref HEAD
>> refs/heads/foo' in the repo.
>>
>> I realise that does not answer "can it be done via git push" but I
>> thought it might help...
>
> Well, if set-head can be extended a bit, it would suit me perfectly.
no reason it can't; shorn of all the argument/access checking, it's a
very simple shell script
--
Sitaram
^ permalink raw reply
* Re: Symbolic refs and the git protocol?
From: Avi Kivity @ 2011-09-25 13:48 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List, John Hawley
In-Reply-To: <CAMK1S_joYUKPXDKyomFdbDP4H0UhcwtNQbC89gvNZOTHowYrLw@mail.gmail.com>
On 09/25/2011 04:42 PM, Sitaram Chamarty wrote:
> On Sun, Sep 25, 2011 at 6:47 PM, Avi Kivity<avi@redhat.com> wrote:
> > With the old kernel.org setup, practically the only think I needed to do on
> > the server itself is the 'git symbolic-ref' command (used to point
> > refs/heads/linux-next at the correct stream).
> >
> > Now it looks like kernel.org will no longer offer shell access. Is it
> > possible to support symbolic-ref via 'git push'?
>
> Can I assume you mean specifically for HEAD, as in 'git symbolic-ref
> HEAD refs/heads/some-branch'?
No, I use them for ordinary branches, for example
git symbolic-ref refs/heads/linux-next refs/heads/kvm-updates/3.2
from this point on, any update to kvm-updates/3.2 will be reflected in
the linux-next ref.
> Although gitolite disables shell access by design, it provides several
> (optionally installed) features to allow specific shell commands to be
> executed. One such command is "set-head", which does exactly what you
> ask. You run it like 'ssh git@server set-head reponame.git
> refs/heads/foo' and it ends up running 'git symbolic-ref HEAD
> refs/heads/foo' in the repo.
>
> I realise that does not answer "can it be done via git push" but I
> thought it might help...
Well, if set-head can be extended a bit, it would suit me perfectly.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Symbolic refs and the git protocol?
From: Sitaram Chamarty @ 2011-09-25 13:42 UTC (permalink / raw)
To: Avi Kivity; +Cc: Git Mailing List, John Hawley
In-Reply-To: <4E7F29EB.8000800@redhat.com>
On Sun, Sep 25, 2011 at 6:47 PM, Avi Kivity <avi@redhat.com> wrote:
> With the old kernel.org setup, practically the only think I needed to do on
> the server itself is the 'git symbolic-ref' command (used to point
> refs/heads/linux-next at the correct stream).
>
> Now it looks like kernel.org will no longer offer shell access. Is it
> possible to support symbolic-ref via 'git push'?
Can I assume you mean specifically for HEAD, as in 'git symbolic-ref
HEAD refs/heads/some-branch'?
Although gitolite disables shell access by design, it provides several
(optionally installed) features to allow specific shell commands to be
executed. One such command is "set-head", which does exactly what you
ask. You run it like 'ssh git@server set-head reponame.git
refs/heads/foo' and it ends up running 'git symbolic-ref HEAD
refs/heads/foo' in the repo.
I realise that does not answer "can it be done via git push" but I
thought it might help...
^ permalink raw reply
* [PATCH] Revert removal of multi-match discard heuristic in 27af01
From: Tay Ray Chuan @ 2011-09-25 13:39 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <4E7B5F28.2020204@lsrfire.ath.cx>
From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
27af01d (xdiff/xprepare: improve O(n*m) performance in
xdl_cleanup_records(), 2011-08-17) was supposed to be a performance
boost only. However, it unexpectedly changed the behaviour of diff.
Revert a part of 27af01d that removes logic that mark lines as
"multi-match" (ie. dis[i] == 2). This was preventing the multi-match
discard heuristic (performed in xdl_cleanup_records() and
xdl_clean_mmatch()) from executing.
Reported-by: Alexander Pepper <pepper@inf.fu-berlin.de>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Junio, this replaces the patch the one in the
'rs/diff-cleanup-records-fix' topic in 'pu'. The only difference is in
the patch message.
René, will need your SOB on this. Thanks for working to produce the
patch. Please disregard my earlier message [1], further reading has
shown my previous understanding to be wrong.
[1] <CALUzUxprUFGMR-WVEMOOvYiwkev1cfxHOyBmZq9bKJcHq5E2VA@mail.gmail.com>
---
xdiff/xprepare.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
index 05a8f01..4c447ca 100644
--- a/xdiff/xprepare.c
+++ b/xdiff/xprepare.c
@@ -398,7 +398,7 @@ static int xdl_clean_mmatch(char const *dis, long i, long s, long e) {
* might be potentially discarded if they happear in a run of discardable.
*/
static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xdf2) {
- long i, nm, nreff;
+ long i, nm, nreff, mlim;
xrecord_t **recs;
xdlclass_t *rcrec;
char *dis, *dis1, *dis2;
@@ -411,16 +411,20 @@ static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xd
dis1 = dis;
dis2 = dis1 + xdf1->nrec + 1;
+ if ((mlim = xdl_bogosqrt(xdf1->nrec)) > XDL_MAX_EQLIMIT)
+ mlim = XDL_MAX_EQLIMIT;
for (i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart]; i <= xdf1->dend; i++, recs++) {
rcrec = cf->rcrecs[(*recs)->ha];
nm = rcrec ? rcrec->len2 : 0;
- dis1[i] = (nm == 0) ? 0: 1;
+ dis1[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
}
+ if ((mlim = xdl_bogosqrt(xdf2->nrec)) > XDL_MAX_EQLIMIT)
+ mlim = XDL_MAX_EQLIMIT;
for (i = xdf2->dstart, recs = &xdf2->recs[xdf2->dstart]; i <= xdf2->dend; i++, recs++) {
rcrec = cf->rcrecs[(*recs)->ha];
nm = rcrec ? rcrec->len1 : 0;
- dis2[i] = (nm == 0) ? 0: 1;
+ dis2[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
}
for (nreff = 0, i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart];
--
1.7.7.rc3.432.g6bcf0
^ permalink raw reply related
* Re: Git for animation studio
From: Jakub Narebski @ 2011-09-25 13:30 UTC (permalink / raw)
To: Will Hoag; +Cc: git
In-Reply-To: <F533627C-C656-4733-8489-B4F62FE79A91@willhoag.com>
Will Hoag <will@willhoag.com> writes:
> I'm doing researching for an online version control systems for our
> developing studio. Wondering how git could work for us in regards to
> large files, lots of data, lots of collaboration etc. I have a basic
> idea of how it works, but I'm very new to version control. Many
> thanks for your help.
What Git *might* have problems with is large un-deltable binary files;
there are however third party tools that try to deal with this
problem, like git-annex, or git-media (git-bigfiles fork is dead
IIRC).
You can [probably] find more information on tools page of Git
Wiki... when it will be up.
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-25 13:24 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <nbd7plmz30x2.mafpxaq9xl9r.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Jakub Narebski wrote:
> > Anyway merging with local changes is an easy way to f**k up your
> > changes in unrecoverable way, IMVHO...
>
> Mercurial backs everything up before doing this merge, so if I do lose my
> local changes, I can start over with this:
>
> hg resolve --unmark --all
> hg resolve --all
Well, that's the advantage of database-like transaction based atomic
operations.
OTOH reflog allows to back out not only last operation...
--
Jakub Narębski
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-25 13:22 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1wllqv48uqfjq.lt9yp4rbxugb.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Seth Robertson wrote:
>
> > As I explained on IRC, you can use the following workflow to create a
> > three way merge.
> >
> > git stash
> > git fetch
> > git merge @{u} stash
> > git mergetool
> > git stash drop
> >
> > You can then do whatever other work you want. You can repeat this
> > workflow as often as you want. When you are done, then you can
> > commit:
> >
> > git commit -a -m "My important work"
> >
> > This is of course easily scriptable so it becomes one command to you.
> > And since you mentioned it, if the merge went poorly and you wanted to
> > start over (only before you dropped the stash of course), you can:
> >
> > git reset --hard HEAD
> > git merge @{u} stash
>
> Thanks. It's a shame, however, that Git makes the user jump through hoops
> to achieve such a simple thing.
A short time after "git stash" was added to Git there was proposal to
automatically use git stash to allow merging with "dirty tree",
i.e. with uncomitted changes. This idea was abandoned, if I remember
it correctly because a.) there were too many corner-cases b.) it
wasn't necessary in most cases.
With merging into branch with uncomitted changes your fairly well
understood 3-way merge (sometimes virtual 3-way merge in the case of
multiple common ancestors) would turn into 4-way merge. Even if you
can automate it somehow (I do wonder how Mercurial manages that),
there could be problem resolving conflicts, unless you happen to touch
different parts of file.
> > Of course, I would recommend you consider some of the more gitish
> > workflows.
>
> And that, I feel, is a problem with Git. In some cases, you can't do
> things how you want -- you have to do things how Git wants.
Please take into account the fact that when you were creating your
workflow to suit your situation you were "forced" to fit it to
Mercurial abilities and best practices. No wonder that it does not
fit Git-ish workflows.
What you use uncomitted changes for, I would use is a separate branch,
and keep it rebasing (something like using 'mq' in Mercurial).
> Another example of this is the lack of support for anonymous branching as
> part of a normal workflow in Git. Anonymous branching is very powerful and
> very simple. I use it all the time in Mercurial.
What do you use anonymous branching for?
Note that with Git by default pushing "matching" branches, you can
create private local-only branches. The have to have _some_ name
(even if it is 'foo/temp'), but I think that it makes them perhaps
more work to create, but easier to use (to switch branches)... and for
single anonymous branch you can always use "detached HEAD".
--
Jakub Narębski
^ permalink raw reply
* Symbolic refs and the git protocol?
From: Avi Kivity @ 2011-09-25 13:17 UTC (permalink / raw)
To: Git Mailing List
With the old kernel.org setup, practically the only think I needed to do
on the server itself is the 'git symbolic-ref' command (used to point
refs/heads/linux-next at the correct stream).
Now it looks like kernel.org will no longer offer shell access. Is it
possible to support symbolic-ref via 'git push'?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH] git-completion: offer remotes for 'git remote update'
From: Auke Schrijnen @ 2011-09-25 12:06 UTC (permalink / raw)
To: git
Completion for 'git remote update' only offers configured remote
groups.
Add all remotes to the completion.
Signed-off-by: Auke Schrijnen <auke@schrijnen.nl>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8648a36..ad2175c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2293,7 +2293,7 @@ _git_remote ()
__gitcomp "$(__git_remotes)"
;;
update)
- local i c='' IFS=$'\n'
+ local i c="$(__git_remotes)" IFS=$'\n'
for i in $(git --git-dir="$(__gitdir)" config --get-regexp
"remotes\..*" 2>/dev/null); do
i="${i#remotes.}"
c="$c ${i/ */}"
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Sitaram Chamarty @ 2011-09-25 12:05 UTC (permalink / raw)
To: Pang Yan Han, Sitaram Chamarty, git, Junio C Hamano,
Shawn O. Pearce, Jeff
In-Reply-To: <20110925094822.GA1702@myhost>
On Sun, Sep 25, 2011 at 3:18 PM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
[snip]
>> It doesn't make sense to disable only the update hook. And although I
>> did not come right out and say it, it is the post-update that I care
>> about. If that still runs, my "issue" still exists.
> Um I'm rather new to Git and the reason why I didn't reply this initially was
> because I didn't know what to reply. Sorry but you sound rather aggressive and
> I was really taken aback by this.
Sorry if I sounded aggressive; I was going to brevity, and levity suffered :-)
[snip lots of stuff about new approach]
> What do you think of this approach (if it's even correct)?
I'm sorry again but it's been almost 2 decades since I did any serious
C and I've never dug into git internals, so I can't tell you if you're
even on the right track. You should wait for one of the other folks
you cc-d to weigh in with their opinions.
Personally, anytime someone says "disable the update hook" I get very
worried -- I've got a heck of a lot invested in update hooks ;-)
I wasn't even *asking* about disabling that; I was asking about
*post*-update, which you didn't even address in your code.
From a philosophical point of view, update and pre-receive *check*
things to make sure everything is OK. IMO they should be allowed to
run even if the ref being deleted doesn't exist -- that could well be
an error condition that the guy who owns the repo wants to trap and
alert himself to in some special way. I would *not* like them
disabled.
Post-{update,receive} are for *after* a successful push. My
suggestion would be to make sure the inputs supplied to those hooks
(via STDIN for post-receive, and as arguments in case of post-update)
reflect this -- only successfully updated refs are sent in as args.
This might mean that in the case of 'git push origin
:refs/heads/non-existent-ref' the post-receive hook would run but
STDIN would be empty, and post-update would run but have no arguments.
That is, IMO, the correct way to deal with this.
^ 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