* Re: Re: Unapplied patches reminder
From: Heiko Voigt @ 2009-10-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <7vbpk4i8ii.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 04:31:49PM -0700, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> > ...
> > From: Heiko Voigt <hvoigt@hvoigt.net>
> > Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> > Date: Wed, 23 Sep 2009 20:30:28 +0200
> > Message-ID: <20090923183023.GA85456@book.hvoigt.net>
> >
> > This is useful if you are using the testsuite with local changes that
> > include activated default hooks suitable for your teams installation.
>
> This may be useful when Heiko or somebody actually has changes that needs
> this fix, but otherwise was an unnecessary code churn during pre-release
> code freeze. I am reasonably sure that Heiko will include it in a series
> that requires this one.
>
> In other words, I am not against it per-se, but I would prefer to see
> patches that actually depends on this change at the same time. Otherwise
> this "is supposed to be no-op, and promises it will help in the future",
> and needs extra mental effort to validate the latter claim.
Well, currently we do not have any activated hooks. They are all sample.
And because the use scenarios for git are so diverse we will probably
never have any default hook activated.
But I imagine that if you are creating a default installation for any
team you will activate some. For an example take this patch:
http://thread.gmane.org/gmane.comp.version-control.git/110874
it is not in master because it was to specific but I have such a hook
activated. It does not allow you to commit on master which breaks the
testsuite.
So in my opinion we should not run the testsuite with hooks even though
the current defaults are all deactivated.
I am afraid that I will never be able to persuade everyone on the list
to not commit on master... ;)
cheers Heiko
P.S.: Just thinking of previous hooks, I might make it an option like
hooks.doNotCommitOnMaster. But still the hooks would be
deactivated.
^ permalink raw reply
* denying branch creation in a shared repository
From: Mohit Aron @ 2009-10-19 8:32 UTC (permalink / raw)
To: git
Hello,
I'm setting up a shared repository and I'd like to prevent users from
creating branches in it (they can of course create local branches in
their own clone of this repository). How can I accomplish this ? I
looked at 'git help config' and it seems I need something similar to
the parameter receive.denyDeletes - this prevents deletion of
branches.
- Mohit
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Sitaram Chamarty @ 2009-10-19 8:43 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On Mon, Oct 19, 2009 at 2:02 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
> Hello,
>
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
That was the main reason I wrote gitolite
(http://github.com/sitaramc/gitolite), though now it does a heck of a
lot more than just that.
Scroll down a bit on that page for the README.
People have said pretty nice things about it on #git, and (subject to
being in India time zone and the day job and all) I make sure I help
out as much as I can. Email or #git, both are fine.
Being somewhat familiar with ssh and authkeys is good. Otherwise,
*please* be sure to read
http://sitaramc.github.com/0-installing/9-gitolite-basics.html for
background
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-19 8:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vws2snwum.fsf@alter.siamese.dyndns.org>
On 2009.10.18 15:47:13 -0700, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:
> > 1) No uncommitted changes => No problem
> > 2) Uncommitted changes merge cleanly => No problem
> > 3) Uncommitted changes causes conflicts =>
> > - User can resolve
> > - User can start over (git update --retry)
> > - User can give up (git update --abort)
>
> By "--abort", if you meant to discard the local change, that is only
> suitable for people who would say "what I was doing was minor anyway, and
> I'll redo them based on the updated upstream", and may not be so useful, I
> think. The user may want to pretend that he did not even start "update"
> (i.e. not pulled while he was still working on something) at this point,
> and if you meant by "give up" (aka --abort) to "reset --hard @{1} &&
> unstash", I think it makes quite a lot of sense. Then the user has an
> option to fork a topic at that point:
>
> git update --abort
> git checkout -b topic
> work on more with committing
> git checkout master
> git update
Yes, I meant the latter. The former would just be "git reset --hard" and
is pointless to be rewrapped in "git update --abort". Maybe "abort" is
the wrong word there? I'm not a native speaker and basically took that
from "git rebase", which returns you to your (unchanged) branch head,
i.e. the state you were in before you started the rebase.
> But then this starts to look more like an enhanced failure recovery mode
> for "git pull" command.
Yeah, I notice that, also while working on my "proof-of-concept"
implementation. Currently, I simply suggest "git pull" to the user when
the update is not a fast-forward one.
I'm probably influenced by a latent hatred for "git pull"... Explaining
that it is fetch+merge/rebase and uses defaults from the config which
are automagically setup is probably something my fingers can do on
their own by now. Confusion about "git pull" probably beats
misunderstandings about HEAD.
If it wasn't so inconvenient for people that actually commit, I'd even
dare to suggest:
git update
- FF update only, using branch.<name>.{remote,merge}
- suggests "git update --merge" or "git update --rebase" if non-ff
git update --merge
- Does a merge
git update --rebase
- Does a rebase
And "git pull" would stop using branch.<name>.{remote,merge} and require
command line arguments.
That would at least raise awareness that "git update --merge" is doing a
merge, unlike "git pull", which many new users simply treat as magic,
not realizing what actually happens (and thus they create butt-ugly
criss-cross merge histories). Of course, I can't tell whether being
aware that a merge happens actually makes the user realize that they
shouldn't update/pull/merge 50 times a day.
But passing --merge all the time seems just too inconvenient. And having
a config option to make --merge or --rebase the default would probably
end up with --merge as the "default default", ultimately turning "git
update" into "git pull".
Anyway, I'm probably getting quite far off the track here.
> In addition, I think that you would internally implement the "save" step
> with "stash" (which would be a sane thing to do), but then you would need
> to worry about the case where the user was in the middle of a merge (or
> "revert", "cherry-pick", "checkout -m") that did not complete. "git pull"
> fails upfront, says why and tells users what to do. "git update" should
> do the same.
Yup, got the same check in my PoC
> > I do see problems with a "stash around merge" thing ("stash" around
> > rebase seems easier, as that could just create a commit and reset later,
> > but I'm not exactly sure that such smartness is a good idea). As soon as
> > the merge has conflicts, you need to know that you have to unstash after
> > committing the merge, but what I have in mind is fast-forward only (or
> > possibly reset, when upstream was rewritten). Primarily for users that
> > don't commit at all, but just look at things [*1*].
>
> Ok. If you have a clean way to guarantee that "update" users won't
> commit, I think the above would sort of make sense and my earlier worries
> about (1) a user who wish he did not fetch and (2) a user who was doing
> something more complex and had conflicts already would go away.
Currently it's just:
test -z "$(git rev-list -1 $upstream..)"
As a "is a fast-forward" check, suggesting the user to use "git pull"
instead of "git update", if it is not. Maybe I should use "git
merge-base" there instead? Is that better? Not sure whether history
simplication might break the rev-list based test...
> If the sole target audience is "minor changes only, never committing"
> people, then I would even rescind my earlier suggestion on --abort; it
> should mean "remove the minor changes and get pristine copy of the
> upstream---the user will redo the minor changes to adjust to the updated
> upstream from scratch", to keep the end user experience simpler and
> clearer.
Hmhm... If the user can't resolve the conflict, but still keep those
changes, he might want to ask someone else for help. And then he might
want to present his changes to that other person, so I think allowing
the user to go back to the old commit with his changes on top is better.
Maybe "git update --drop" could do the "drop the user's changes", if the
user wants to do so. No support for going back is what's bad about "svn
update" (and, I guess, "git checkout --merge").
> I am undecided if it is a good thing to divide the userbase into two
> classes, "update" people and "work-commit-fetch-merge-resolve" people.
I expect that there are already two userbases. Developers in one
userbase and users that just want the latest code in the other. And
these users might have some uncommitted stuff (either self-made or
possibly found somewhere, or maybe a bit of both).
I just wonder what's easier/better: to cater to each one or trying to
unify them by trying to educate the one that actually doesn't care.
Björn
^ permalink raw reply
* Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit
From: Junio C Hamano @ 2009-10-19 8:50 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <499EF2B6.7060103@hvoigt.net>
Heiko Voigt <git-list@hvoigt.net> writes:
> It sometimes happens that you move to a new machine and forget to setup your
> name and email address. To find this out after 10 commits can be quite
> frustrating.
Doesn't env_hint[] kick in in fmt_ident() in such a case, though?
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Björn Steinbrink @ 2009-10-19 8:51 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On 2009.10.19 01:32:24 -0700, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
You could write a pre-receive or update hook (depending on whether you
want the whole push to fail, or just the branch head creation, see
githooks(5)).
If a ref is created, the old value is 40 0 (just zeros, forty of them).
And if the refname starts with refs/heads/, then a branch head is being
created. And in that case, you could refuse the push.
Björn
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Sixt @ 2009-10-19 9:11 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T094924-194@post.gmane.org>
Sergio Callegari schrieb:
> Is there a means to have fsck to a truly full check on the sanity of a repo?
git fsck --full
RTFM, please.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johan Herland @ 2009-10-19 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7vhbtv6c76.fsf@alter.siamese.dyndns.org>
On Monday 19 October 2009, Junio C Hamano wrote:
> * jh/notes (2009-10-09) 22 commits.
> - fast-import: Proper notes tree manipulation using the notes API
> - Refactor notes concatenation into a flexible interface for combining notes
> - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> - Notes API: get_note(): Return the note annotating the given object
> - Notes API: add_note(): Add note objects to the internal notes tree structure
> - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> - Add selftests verifying concatenation of multiple notes for the same commit
> - Refactor notes code to concatenate multiple notes annotating the same object
> - Add selftests verifying that we can parse notes trees with various fanouts
> - Teach the notes lookup code to parse notes trees with various fanout schemes
> - Teach notes code to free its internal data structures on request
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note string
> - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
> (this branch uses sr/gfi-options.)
Nope. This branch does not use sr/gfi-options. The jh/cvs-helper branch
does, though.
> Is this good for 'next' now?
Not all of it.
I suspect the first 14 patches are stable and 'next'-worthy, although
it would be nice if Dscho had the time to ACK them.
The last patch (#22) needs some major rework based on Shawn's comments
(I'm working on that, although I currently have less time than I hoped
for), and that rework might ripple into patches #15 through #21.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Moving git
From: rhlee @ 2009-10-19 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <20091016184251.GG19511@inocybe.localdomain>
Thanks, I've been looking for something like EPEL for a long time.
--
View this message in context: http://n2.nabble.com/Moving-git-tp3836198p3848039.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 9:57 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
Hi,
On Mon, 19 Oct 2009, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to the
> parameter receive.denyDeletes - this prevents deletion of branches.
The easiest way to accomplish things is to look who had the same problem
and solved it:
http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
Hth,
Dscho
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Schindelin @ 2009-10-19 10:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio Callegari, git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Hi,
On Mon, 19 Oct 2009, Johannes Sixt wrote:
> Sergio Callegari schrieb:
> > Is there a means to have fsck to a truly full check on the sanity of a
> > repo?
>
> git fsck --full
>
> RTFM, please.
Now, now.
If you were to test a new filesystem, say, wonderfulfs, and wanted to
check its integrity, would you not just run "fsck-wonderfulfs" if that
exists, rather than reading the fantamagastic manual? Would you not
expect that it Does The Right Thing? Would you not expect that it
follows the Law Of Minimal Surprise?
So FWIW I can see where Sergio is coming from.
Ciao,
Dscho
^ permalink raw reply
* Which dates 'git log --since= --after=' compare?
From: Daniel @ 2009-10-19 10:01 UTC (permalink / raw)
To: git
Hi,
I can see that 'git log --since= --after=' compares commit's dates,
not author's dates.How can I limit commits by Author's date?
$ git log --format="%aD %cD"
Mon, 5 Oct 2009 14:54:57 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 11:11:35 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 10:14:41 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 14:23:30 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 10:27:39 +0200 Thu, 8 Oct 2009 10:31:38 +0200
Wed, 16 Sep 2009 09:15:32 +0200 Thu, 8 Oct 2009 10:30:31 +0200
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
$ git log --format="%aD %cD" --since=2009-09-01 --until=2009-10-01
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
--
Daniel
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191155310.4985@pacific.mpi-cbg.de>
Hi,
I'm quite interested in this too but I can't see what that patch does
at all. I'm unsure what the 'mob' account is but a search suggests
it's something to do with anonymous access, which doesn't seem to make
any sense.
Can you explain?
Thanks!
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 19 Oct 2009, Mohit Aron wrote:
>
>> I'm setting up a shared repository and I'd like to prevent users from
>> creating branches in it (they can of course create local branches in
>> their own clone of this repository). How can I accomplish this ? I
>> looked at 'git help config' and it seems I need something similar to the
>> parameter receive.denyDeletes - this prevents deletion of branches.
>
> The easiest way to accomplish things is to look who had the same problem
> and solved it:
>
> http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
>
> Hth,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Sergio Callegari @ 2009-10-19 10:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Johannes Sixt wrote:
> Sergio Callegari schrieb:
>
>> Is there a means to have fsck to a truly full check on the sanity of a repo?
>>
>
> git fsck --full
>
> RTFM, please.
>
>
Right... sorry for the noise, I mismatched --strict for --full in a script.
BTW, the short help for fsck at --full only says "consider objects in
alternate repositories".
My apologize.
Sergio
^ permalink raw reply
* Re: Potentially dangerous behavior of git gc
From: Miklos Vajna @ 2009-10-19 11:21 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T095725-840@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari <sergio.callegari@gmail.com> wrote:
> With this when the alternate info of A is finally updated, A is broken, missing
> many references and not having a head anymore.
>
> Would it be better to have git gc not to take dangerous actions on potentially
> problematic repos?
Such repos are usually created using git clone -s. See the NOTE of the
manpage under the -s option, probably you want to use git repack -a
after git clone.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Unapplied patches reminder
From: Rolf Bjarne Kvinge @ 2009-10-19 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vzl7ogtxs.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On Mon, 19 Oct 2009 01:31:59 +0200, Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, I saw these patches and thought what they try to do were
>> sensible, but I don't them in your tree. I didn't see much discussion
>> on most of them, either.
>>
>> Because I don't read C very well, I may have listed some patches
>> here that you may have discarded because the code was no good, and
>> if so I apologize for wasting your time, but I thought at least
>> some of them should be salvaged.
>> ...
>> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
>> Subject: git rev-list --pretty=raw strips empty lines
>> Date: Tue, 06 Oct 2009 14:33:37 +0200
>> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>>
>> It seems like the --pretty=raw format strips off empty newlines from
>> the beginning of log messages, while I'd expect the raw format to
>> not do any transformations (just as the documentation says: "The
>> 'raw' format shows the entire commit exactly as stored in the commit
>> object").
>>
>> The below changes works for me, not sure if I'm right about this
>> though (my first time here ;-)
>
> I do not recall seeing this one; most likely it was lost in the noise,
> especially because it did not look like a patch submission, without having
> anything resembling a commit log message.
>
> I think the change itself is an uncontroversial one, even though this
> really changes the behaviour.
My specific need is to be able to get out the exact same log message as I committed, another way of getting the same result would be to implement --pretty=xml (along the lines of subversions 'svn log --xml'). This would prevent behavioural changes. And yes, I'm willing to implement it if you agree it's a good idea.
Regarding the previous patch I just found that it's not complete - git would still print lines with only whitespace as empty lines (i.e. stripping off the whitespace). I'm attaching a revised patch that fixes this issue, but since I found the resulting code slightly ugly, I also found an easier approach: in pretty_print_commit (pretty.c) just print the commit message buffer and return.
Rolf
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: 0001-pretty.c-Don-t-do-any-transformations-when-using-the.patch --]
[-- Type: application/octet-stream, Size: 0 bytes --]
[-- Attachment #3: 0001-pretty.c-special-case-raw-format.patch --]
[-- Type: application/octet-stream, Size: 874 bytes --]
From 4fa9e4c1c133fbe3423c979efd5722dd7bd5d530 Mon Sep 17 00:00:00 2001
From: Rolf Bjarne Kvinge <RKvinge@novell.com>
Date: Mon, 19 Oct 2009 13:31:17 +0200
Subject: [PATCH] pretty.c: Don't do any transformations when using the 'raw' format.
When formatting commits with the 'raw' format, print the commit exactly as
stored.
Signed-off-by: Rolf Bjarne Kvinge <RKvinge@novell.com>
---
pretty.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index f5983f8..96dac9a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -915,6 +915,11 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
return;
}
+ if (fmt == CMIT_FMT_RAW) {
+ strbuf_add(sb, msg, strlen (msg));
+ return;
+ }
+
reencoded = reencode_commit_message(commit, &encoding);
if (reencoded) {
msg = reencoded;
--
1.6.5.rc2.17.gdbc1b.dirty
^ permalink raw reply related
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 12:00 UTC (permalink / raw)
To: Howard Miller; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190308t3233debdjfc0c8beedb9c0ac6@mail.gmail.com>
Hi,
first, if you want to be taken seriously, you might want to avoid to
top-post.
Second, do diligent research (e.g. on the 'mob' user).
On Mon, 19 Oct 2009, Howard Miller wrote:
> I'm quite interested in this too but I can't see what that patch does at
> all. I'm unsure what the 'mob' account is but a search suggests it's
> something to do with anonymous access, which doesn't seem to make any
> sense.
If this trivial script (_not_ a patch! This should be obvious at first
sight) does not make any sense to you, I fear you will not be able to use
hooks to do what you want to do.
> Can you explain?
Yes.
The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
that exists. IOW a user of repo.or.cz can decide to let random people to
push commits by creating the 'mob' branch and adding the 'mob' user to the
pushers.
The first part of the hook (as you can see from the pretty helpful error
messages it outputs) is about denying to push to anything but the mob
branch.
The second part is much more interesting in the context of this thread
(and I would expect anyone capable of reading shell scripts to see that
readily), because it denies the 'mob' user to _create_ the 'mob' branch.
See line 16ff.
So the point is: the update hook gets a "$2" = 0000... in case a branch is
about to be created, and the hook can prevent that by exiting with a
non-zero exit code.
Hth,
Dscho
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191353080.4985@pacific.mpi-cbg.de>
Mmm....
Thanks for the helpful reply Johannes. Perhaps you should do diligent
research into mail software that folds quoted text for you. There's a
company called Google you might have heard of. Just a thought.
On the other hand if you can't be bothered making a helpful reply
rather than a rude one perhaps simply not writing anything at all
would, at the very least, leave us absolutely no worse off. Just the
opinion of someone not to be taken seriously.... of course!
Howard
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> first, if you want to be taken seriously, you might want to avoid to
> top-post.
>
> Second, do diligent research (e.g. on the 'mob' user).
>
> On Mon, 19 Oct 2009, Howard Miller wrote:
>
>> I'm quite interested in this too but I can't see what that patch does at
>> all. I'm unsure what the 'mob' account is but a search suggests it's
>> something to do with anonymous access, which doesn't seem to make any
>> sense.
>
> If this trivial script (_not_ a patch! This should be obvious at first
> sight) does not make any sense to you, I fear you will not be able to use
> hooks to do what you want to do.
>
>> Can you explain?
>
> Yes.
>
> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
> that exists. IOW a user of repo.or.cz can decide to let random people to
> push commits by creating the 'mob' branch and adding the 'mob' user to the
> pushers.
>
> The first part of the hook (as you can see from the pretty helpful error
> messages it outputs) is about denying to push to anything but the mob
> branch.
>
> The second part is much more interesting in the context of this thread
> (and I would expect anyone capable of reading shell scripts to see that
> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
> See line 16ff.
>
> So the point is: the update hook gets a "$2" = 0000... in case a branch is
> about to be created, and the hook can prevent that by exiting with a
> non-zero exit code.
>
> Hth,
> Dscho
>
>
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190519mbe9ddaava3c15de94a0cd14f@mail.gmail.com>
And... I instantly have to apologise.. With wonderful irony,
Googlemail folded the helpful bit of your reply leaving just the
(apparently) unhelpful bit.
(Crawls under nearest rock).
2009/10/19 Howard Miller <howard@e-learndesign.co.uk>:
> Mmm....
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
>
> On the other hand if you can't be bothered making a helpful reply
> rather than a rude one perhaps simply not writing anything at all
> would, at the very least, leave us absolutely no worse off. Just the
> opinion of someone not to be taken seriously.... of course!
>
> Howard
>
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> first, if you want to be taken seriously, you might want to avoid to
>> top-post.
>>
>> Second, do diligent research (e.g. on the 'mob' user).
>>
>> On Mon, 19 Oct 2009, Howard Miller wrote:
>>
>>> I'm quite interested in this too but I can't see what that patch does at
>>> all. I'm unsure what the 'mob' account is but a search suggests it's
>>> something to do with anonymous access, which doesn't seem to make any
>>> sense.
>>
>> If this trivial script (_not_ a patch! This should be obvious at first
>> sight) does not make any sense to you, I fear you will not be able to use
>> hooks to do what you want to do.
>>
>>> Can you explain?
>>
>> Yes.
>>
>> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
>> that exists. IOW a user of repo.or.cz can decide to let random people to
>> push commits by creating the 'mob' branch and adding the 'mob' user to the
>> pushers.
>>
>> The first part of the hook (as you can see from the pretty helpful error
>> messages it outputs) is about denying to push to anything but the mob
>> branch.
>>
>> The second part is much more interesting in the context of this thread
>> (and I would expect anyone capable of reading shell scripts to see that
>> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
>> See line 16ff.
>>
>> So the point is: the update hook gets a "$2" = 0000... in case a branch is
>> about to be created, and the hook can prevent that by exiting with a
>> non-zero exit code.
>>
>> Hth,
>> Dscho
>>
>>
>
^ permalink raw reply
* Re: [PATCH] Add the --submodule option to the diff option family
From: Jens Lehmann @ 2009-10-19 12:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3a5gdr1c.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> I have four patches queued on js/diff-verbose-submodule topic and I think
> this corresponds to the first three, correct?
Yes.
>> +--submodule[=<format>]::
>> + Chose the output format for submodule differences. <format> can be one of
>> + 'short' and 'left-right-log'. 'short' is the default value for this
>> + option and and shows pairs of commit names. 'left-right-log' lists the
>> + commits in that commit range like the 'summary' option of
>> + linkgit:git-submodule[1] does.
>> +
>
> Well, while left-right-log may be logically the most correct name for this
> option, I think it is too long to be practical. Because it is not like we
> would want to have an option to have full log there when we are showing
> "diff", I think it would make sense to making left-right-log the default
> when "--submodule" (without format specification) is given, and possibly
> give "--submodule=log" as the synonym for this format.
O.k., "--submodule=log" it is.
> After all, if you do not give --submodule, we will give the traditional
> short format, no?
Yes. Will make the documentation clearer on this.
>> diff --git a/diff.c b/diff.c
>> index c719ce2..8af1ae2 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -2771,6 +2783,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
>> DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
>> else if (!strcmp(arg, "--ignore-submodules"))
>> DIFF_OPT_SET(options, IGNORE_SUBMODULES);
>> + else if (!prefixcmp(arg, "--submodule=")) {
>> + if (!strcmp(arg + 12, "left-right-log"))
>> + DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
>> + }
>
> I do not see --submodule (without "=<format>") supported here as the
> documentation claims, but this is the logical place to do so.
Will change that.
>> diff --git a/submodule.c b/submodule.c
>> new file mode 100644
>> index 0000000..206386f
>> --- /dev/null
>> +++ b/submodule.c
>> @@ -0,0 +1,112 @@
>> +...
>> +void show_submodule_summary(FILE *f, const char *path,
>> + unsigned char one[20], unsigned char two[20],
>> + const char *del, const char *add, const char *reset)
>> +{
>> ...
>> + fwrite(sb.buf, sb.len, 1, f);
>> +
>> + if (!message) {
>> + while ((commit = get_revision(&rev))) {
>> + ...
>> + }
>> + clear_commit_marks(left, ~0);
>> + clear_commit_marks(right, ~0);
>> + }
>> +}
>
> I thought we had strbuf_release(&sb) here... Where did it go?
*blush* ... thanks for catching this, will put it back where it belongs.
^ permalink raw reply
* [PATCH v2] Add the --submodule option to the diff option family
From: Jens Lehmann @ 2009-10-19 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4ADC5BB7.5090207@web.de>
When you use the option --submodule=log you can see the submodule
summaries inlined in the diff, instead of not-quite-helpful SHA-1 pairs.
The format imitates what "git submodule summary" shows.
To do that, <path>/.git/objects/ is added to the alternate object
databases (if that directory exists).
This option was requested by Jens Lehmann at the GitTogether in Berlin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Changes since v1:
- Changed the option name from "left-right-log" to "log"
- Handling "--submodule"-option without extra arguments now
- Re-added a "strbuf_release(&sb);" being accidentally dropped
- Changed the wording in the Documentation
Documentation/diff-options.txt | 7 +++
Makefile | 2 +
diff.c | 18 ++++++
diff.h | 1 +
submodule.c | 113 ++++++++++++++++++++++++++++++++++++++++
submodule.h | 8 +++
6 files changed, 149 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9276fae..e26b847 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -87,6 +87,13 @@ endif::git-format-patch[]
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
+--submodule[=<format>]::
+ Chose the output format for submodule differences. <format> can be one of
+ 'short' and 'log'. 'short' just shows pairs of commit names, this format
+ is used when this option is not given. 'log' is the default value for this
+ option and lists the commits in that commit range like the 'summary'
+ option of linkgit:git-submodule[1] does.
+
--color::
Show colored diff.
diff --git a/Makefile b/Makefile
index c0eff64..2f61e17 100644
--- a/Makefile
+++ b/Makefile
@@ -453,6 +453,7 @@ LIB_H += sideband.h
LIB_H += sigchain.h
LIB_H += strbuf.h
LIB_H += string-list.h
+LIB_H += submodule.h
LIB_H += tag.h
LIB_H += transport.h
LIB_H += tree.h
@@ -551,6 +552,7 @@ LIB_OBJS += sideband.o
LIB_OBJS += sigchain.o
LIB_OBJS += strbuf.o
LIB_OBJS += string-list.o
+LIB_OBJS += submodule.o
LIB_OBJS += symlinks.o
LIB_OBJS += tag.o
LIB_OBJS += trace.o
diff --git a/diff.c b/diff.c
index c719ce2..5fc9f37 100644
--- a/diff.c
+++ b/diff.c
@@ -13,6 +13,7 @@
#include "utf8.h"
#include "userdiff.h"
#include "sigchain.h"
+#include "submodule.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -1557,6 +1558,17 @@ static void builtin_diff(const char *name_a,
const char *a_prefix, *b_prefix;
const char *textconv_one = NULL, *textconv_two = NULL;
+ if (DIFF_OPT_TST(o, SUBMODULE_LEFT_RIGHT_LOG) &&
+ (!one->mode || S_ISGITLINK(one->mode)) &&
+ (!two->mode || S_ISGITLINK(two->mode))) {
+ const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
+ const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
+ show_submodule_summary(o->file, one ? one->path : two->path,
+ one->sha1, two->sha1,
+ del, add, reset);
+ return;
+ }
+
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
textconv_one = get_textconv(one);
textconv_two = get_textconv(two);
@@ -2771,6 +2783,12 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--submodule"))
+ DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
+ else if (!prefixcmp(arg, "--submodule=")) {
+ if (!strcmp(arg + 12, "log"))
+ DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
+ }
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/diff.h b/diff.h
index a7e7ccb..8079f5b 100644
--- a/diff.h
+++ b/diff.h
@@ -67,6 +67,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
#define DIFF_OPT_DIFF_FROM_CONTENTS (1 << 22)
+#define DIFF_OPT_SUBMODULE_LEFT_RIGHT_LOG (1 << 23)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/submodule.c b/submodule.c
new file mode 100644
index 0000000..d5fce7a
--- /dev/null
+++ b/submodule.c
@@ -0,0 +1,113 @@
+#include "cache.h"
+#include "submodule.h"
+#include "dir.h"
+#include "diff.h"
+#include "commit.h"
+#include "revision.h"
+
+int add_submodule_odb(const char *path)
+{
+ struct strbuf objects_directory = STRBUF_INIT;
+ struct alternate_object_database *alt_odb;
+
+ strbuf_addf(&objects_directory, "%s/.git/objects/", path);
+ if (!is_directory(objects_directory.buf))
+ return -1;
+
+ /* avoid adding it twice */
+ for (alt_odb = alt_odb_list; alt_odb; alt_odb = alt_odb->next)
+ if (alt_odb->name - alt_odb->base == objects_directory.len &&
+ !strncmp(alt_odb->base, objects_directory.buf,
+ objects_directory.len))
+ return 0;
+
+ alt_odb = xmalloc(objects_directory.len + 42 + sizeof(*alt_odb));
+ alt_odb->next = alt_odb_list;
+ strcpy(alt_odb->base, objects_directory.buf);
+ alt_odb->name = alt_odb->base + objects_directory.len;
+ alt_odb->name[2] = '/';
+ alt_odb->name[40] = '\0';
+ alt_odb->name[41] = '\0';
+ alt_odb_list = alt_odb;
+ prepare_alt_odb();
+ return 0;
+}
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset)
+{
+ struct rev_info rev;
+ struct commit *commit, *left = left, *right;
+ struct commit_list *merge_bases, *list;
+ const char *message = NULL;
+ struct strbuf sb = STRBUF_INIT;
+ static const char *format = " %m %s";
+ int fast_forward = 0, fast_backward = 0;
+
+ if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (add_submodule_odb(path))
+ message = "(not checked out)";
+ else if (is_null_sha1(one))
+ message = "(new submodule)";
+ else if (!(left = lookup_commit_reference(one)) ||
+ !(right = lookup_commit_reference(two)))
+ message = "(commits not present)";
+
+ if (!message) {
+ init_revisions(&rev, NULL);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.left_right = 1;
+ rev.first_parent_only = 1;
+ left->object.flags |= SYMMETRIC_LEFT;
+ add_pending_object(&rev, &left->object, path);
+ add_pending_object(&rev, &right->object, path);
+ merge_bases = get_merge_bases(left, right, 1);
+ if (merge_bases) {
+ if (merge_bases->item == left)
+ fast_forward = 1;
+ else if (merge_bases->item == right)
+ fast_backward = 1;
+ }
+ for (list = merge_bases; list; list = list->next) {
+ list->item->object.flags |= UNINTERESTING;
+ add_pending_object(&rev, &list->item->object,
+ sha1_to_hex(list->item->object.sha1));
+ }
+ if (prepare_revision_walk(&rev))
+ message = "(revision walker failed)";
+ }
+
+ strbuf_addf(&sb, "Submodule %s %s..", path,
+ find_unique_abbrev(one, DEFAULT_ABBREV));
+ if (!fast_backward && !fast_forward)
+ strbuf_addch(&sb, '.');
+ strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
+ if (message)
+ strbuf_addf(&sb, " %s\n", message);
+ else
+ strbuf_addf(&sb, "%s:\n", fast_backward ? " (rewind)" : "");
+ fwrite(sb.buf, sb.len, 1, f);
+
+ if (!message) {
+ while ((commit = get_revision(&rev))) {
+ strbuf_setlen(&sb, 0);
+ if (commit->object.flags & SYMMETRIC_LEFT) {
+ if (del)
+ strbuf_addstr(&sb, del);
+ }
+ else if (add)
+ strbuf_addstr(&sb, add);
+ format_commit_message(commit, format, &sb,
+ rev.date_mode);
+ if (reset)
+ strbuf_addstr(&sb, reset);
+ strbuf_addch(&sb, '\n');
+ fprintf(f, "%s", sb.buf);
+ }
+ clear_commit_marks(left, ~0);
+ clear_commit_marks(right, ~0);
+ }
+ strbuf_release(&sb);
+}
diff --git a/submodule.h b/submodule.h
new file mode 100644
index 0000000..4c0269d
--- /dev/null
+++ b/submodule.h
@@ -0,0 +1,8 @@
+#ifndef SUBMODULE_H
+#define SUBMODULE_H
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset);
+
+#endif
--
1.6.5.104.gd732a
^ permalink raw reply related
* Re: denying branch creation in a shared repository
From: Thomas Rast @ 2009-10-19 12:59 UTC (permalink / raw)
To: Howard Miller; +Cc: Johannes Schindelin, Mohit Aron, git
In-Reply-To: <26ae428a0910190519mbe9ddaava3c15de94a0cd14f@mail.gmail.com>
Howard Miller wrote:
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >
> > first, if you want to be taken seriously, you might want to avoid to
^^^^^^^^^
> > top-post.
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
It really is about the "seriously". If you don't, you'll get your
mail outright ignored.
Many of us get lots[1] of mail per day, and have no time nor will to
scroll around in the message reading long (untrimmed) quoted parts
that are out of order, let alone click around in the corresponding
thread to remember the context. If you want your mail to be read, you
should take some time to make it *easy* to read on its own.
[1] I'm luckily not one of them, but I hear high-profile project
maintainers get hundreds.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 13:12 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, Mohit Aron, git
In-Reply-To: <200910191459.40332.trast@student.ethz.ch>
>
> Many of us get lots[1] of mail per day, and have no time nor will to
> scroll around in the message reading long (untrimmed) quoted parts
> that are out of order, let alone click around in the corresponding
> thread to remember the context. If you want your mail to be read, you
> should take some time to make it *easy* to read on its own.
>
I forgot and I apologise unreservedly. I am in a similar position on
other projects although we use web forums which makes it easier. I
certainly don't want to get into that argument though. I struggle a
great deal to be nice to people who haven't made any kind of effort to
even ask a sensible question so I do understand. The challenge is to
think someone is stupid yet to manage a polite, constructive and
non-arrogant reply (or just say nothing if you can't). At least web
forums have emoticons - a smiley fixes everything!!
Gentlemen... keep up the good work. Even an idiot like me thinks that
git is a fantastic project. It has saved me hours of pain and effort.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Per Strandh @ 2009-10-19 13:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vzl7ogtxs.fsf@alter.siamese.dyndns.org>
"Junio C Hamano" <gitster@pobox.com> skrev i meddelandet
news:7vzl7ogtxs.fsf@alter.siamese.dyndns.org...
>> From: Per Strandh <Per.Strandh@q-matic.se>
>> Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
>> Date: Tue, 13 Oct 2009 22:09:12 +0200
>> Message-ID:
>> <65D9329CA2AF94438F542D48F2A42E830F95F51514@GOT-SRV-005.QMATIC.local>
>>
>> git-p4 clone (and sync) did not work if the specified depot path
>> contained spaces.
>> Fixed by quoting the argument to the "p4 changes" and "p4 files"
>> commands.
>
> I do recall ignoring this one because (1) I never use git-p4 myself and
> always rely on Acks from people who have been involved in it, and (2) the
> message was mangled (perhaps it had two or three copies of patches as
> attachments).
Sorry for posting a mangled patch.
Please let someone involved in the git-p4 code review/approve/apply the
patch.
Regards
/Per/
>From c70682a9c4051f2dc92e2dd92f1710c755df6cfe Mon Sep 17 00:00:00 2001
From: Per Strandh <per.strandh@q-matic.se>
Date: Fri, 9 Oct 2009 12:11:14 +0200
Subject: [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot
path
git-p4 clone (and sync) did not work if the specified depot path contained
spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p,
changeRange)
- for p in
depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p,
changeRange)
+ for p in
depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) +
"\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
^ permalink raw reply related
* Re: How to revert one of multiple merges
From: Michael J Gruber @ 2009-10-19 15:19 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <19162.32265.738503.382638@lisa.zopyra.com>
Bill Lear venit, vidit, dixit 18.10.2009 04:31:
> Branch A, B, C each have 20 commits, 0-19.
>
> Branch v1.0.0 created, then merge of A, B, C performed.
>
> After testing, we realize that the branch B is not ready for
> production release and we'd like to remove it from branch
> v1.0.0.
>
> If I do
>
> % git merge A B C
>
> I get a single commit:
>
> % git log -p
>
> commit 1644a0b98c01869aa83e59aa41374c22098c47b6
> [...]
> Date: Fri Oct 16 09:52:32 2009 -0500
>
> Merge branches 'A', 'B' and 'C' into v1.0.0
>
> [20 x 3 commits]
>
> If I do
>
> % git merge A
> % git merge B
> % git merge C
>
> Then:
>
> % git log -p
>
> commit 8946edd381384d0882221c87b5b3b7bf47127d70
> [...]
> Date: Sat Oct 17 21:28:36 2009 -0500
>
> Merge branch 'B' into v1.0.0
>
> commit 076ed422443e3684e564f7cae2b92e4538088ae6
> [...]
> Date: Sat Oct 17 21:28:35 2009 -0500
>
> Merge branch 'A' into v1.0.0
>
> but no "Merge branch 'C' into v1.0.0".
Do you get any commits after the merge of B? If yes, then v1.0.0 got
fast-forwarded (you can avoid that using --no-ff). If no, C was
contained in v1.0.0 already.
In both cases, it's not clear how C could have been "ready" when B was not.
> And so, I'm faced with git rebase -i posing some unanswerable questions
> to our release manager. She cannot easily remove B from the merge after
> doint either merge A B C, or merge A, merge B, merge C.
The way you described the situation there are no commits after the
merges. So, why not reset to before the merge and do a "git merge A C"?
Michael
^ 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