* Re: [PATCH v4 2/4] completion: simplify __git_remotes
From: Felipe Contreras @ 2012-02-06 21:04 UTC (permalink / raw)
To: SZEDER Gábor
Cc: git, Junio C Hamano, Jonathan Nieder, Thomas Rast, Todd Zullinger,
Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20120206205315.GI16099@goldbirke>
2012/2/6 SZEDER Gábor <szeder@ira.uka.de>:
> On Thu, Feb 02, 2012 at 10:30:23PM +0200, Felipe Contreras wrote:
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index b435b6d..f86b734 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -644,12 +644,7 @@ __git_refs_remotes ()
>> __git_remotes ()
>> {
>> local i ngoff IFS=$'\n' d="$(__gitdir)"
>
> You could also remove the ngoff variable, because with this patch it's
> not used anymore.
Right, I thought I did that... The change must have been lost in one
of the many revisions =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 2/4] completion: simplify __git_remotes
From: SZEDER Gábor @ 2012-02-06 20:53 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jonathan Nieder, Thomas Rast, Todd Zullinger,
Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1328214625-3576-3-git-send-email-felipe.contreras@gmail.com>
Hi,
On Thu, Feb 02, 2012 at 10:30:23PM +0200, Felipe Contreras wrote:
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b435b6d..f86b734 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -644,12 +644,7 @@ __git_refs_remotes ()
> __git_remotes ()
> {
> local i ngoff IFS=$'\n' d="$(__gitdir)"
You could also remove the ngoff variable, because with this patch it's
not used anymore.
> - __git_shopt -q nullglob || ngoff=1
> - __git_shopt -s nullglob
> - for i in "$d/remotes"/*; do
> - echo ${i#$d/remotes/}
> - done
> - [ "$ngoff" ] && __git_shopt -u nullglob
> + test -d "$d/remotes" && ls -1 "$d/remotes"
> for i in $(git --git-dir="$d" config --get-regexp 'remote\..*\.url' 2>/dev/null); do
> i="${i#remote.}"
> echo "${i/.url*/}"
> --
> 1.7.9
>
^ permalink raw reply
* Re: Git performance results on a large repository
From: Joshua Redstone @ 2012-02-06 20:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Joey Hess, dgma@mohsinc.com, Matt Graham,
Tomas Carnecky, Greg Troxel, david@lang.hm, David Barr
Cc: git@vger.kernel.org
In-Reply-To: <CALts4TRGj1_uPX2b86GyfHHcDAUp6JSSMGmKjfS0p79DSAZ_uA@mail.gmail.com>
Hi all,
Nguyen, thanks for pointing out the assume-unchanged part. That, and
especially the suggestion of making assume-unchanged files read-only is
interesting. It does require explicit specification of what's changed.
Hmm, I wonder if that could be a candidate API through which something
like CoW file system could let git know what's changed. Btw, I think you
asked earlier, but the index compresses from 158MB to 58MB - keep in mind
that the majority of file names in the repo are synthetic, so take with
big grain of salt.
Joey, it sounds like it might be good if git-mv and other commands where
consistent in how they treat the assume-unchanged bit.
David Mohs: Yeah, it's an open question whether we'd be better off
somehow forcing the repos the split apart more. As a practical matter,
what may happen is that we incrementally solve our problem by addressing
pain points as they come up (e.g., git status being slow). One risk with
that approach is that it leads to overly short-term thinking and we get
stuck in a local minimum. I totally agree that good modularization and
code health is valuable. I think sometimes that getting to good
modularization does involve some technical work - like maybe moving
functionality between systems so they split apart better, having some
notion of versioning and dependency and managing that, and so forth. I
suppose the other aspect to the problem is that we want to make sure we
have a good source-control story even if the modularization effort takes a
long time - we'd rather not end up in a race between long-term
modularization efforts and source-control performance going south too
fast. I suppose this comes back to the desire that modularization not be
a prerequisite for good source-control performance. Oh, and in case I
didn't mention it - we are working on modularization and splitting off
large chunks of code, both into separable libraries as well as into
separate services, but it's a long-term process.
Matt, some of our repos are still on SVN, many are on pure-git. One of
the main ones that is on SVN is, at least at the moment, not amenable to
sparse checkouts because of it's structure.
Tomas, yeah, I think one of the big questions is how little technical work
can we get away with, and where's the point of maximum leverage in terms
of how much engineering time we invest.
Greg, 'git commit' does some stat'ing of every file, even with all those
flags - for example, I think one instance it does it is, just in case any
pre-commit hooks touched any files, it re-stats everything. Regarding the
perf numbers, I ran it on a beefy linux box. Have you tried doing your
measurements with the drop_caches trick to make sure the file cache is
totally cold? Sorry for the dumb question, but how do I check the vnode
cache size?
David Lang and David Barr, I generated the pack files by doing a repack:
"git repack -a -d -f --max-pack-size=10g --depth=100 --window=250" after
generating the repo.
One other update, the command I was running to get a histogram of all
files in the repo finally completed. The histogram (counting file size in
bytes) is:
[ 0.0 - 6.4): 3
[ 6.4 - 41.3): 27
[ 41.3 - 265.7): 6
[ 265.7 - 1708.1): 652594
[ 1708.1 - 10980.6): 673482
[ 10980.6 - 70591.6): 19519
[ 70591.6 - 453814.3): 1583
[ 453814.3 - 2917451.4): 276
[ 2917451.4 - 18755519.0): 61
[18755519.0 - 120574242.0]: 4
n=1347555 mean=3697.917708, median=1770.000000, stddev=122940.890559
The smaller files are all text (code), and the large ones are probably
binary.
Cheers,
Josh
On 2/6/12 11:23 AM, "Matt Graham" <mdg149@gmail.com> wrote:
>On Sat, Feb 4, 2012 at 18:05, Joshua Redstone <joshua.redstone@fb.com>
>wrote:
>> [ wanted to reply to my initial msg, but wasn't subscribed to the list
>>at time of mailing, so replying to most recent post instead ]
>>
>> Matt Graham: I don't have file stats at the moment. It's mostly code
>>files, with a few larger data files here and there. We also don't do
>>sparse checkouts, primarily because most people use git (whether on top
>>of SVN or not), which doesn't support it.
>
>
>This doesn't help your original goal, but while you're still working
>with git-svn, you can do sparse checkouts. Use --ignore-paths when you
>do the original clone and it will filter out directories that are not
>of interest.
>
>We used this at Etsy to keep git svn checkouts manageable when we
>still had a gigantic svn repo. You've repeatedly said you don't want
>to reorganize your repos but you may find this writeup informative
>about how Etsy migrated to git (which included a health amount of repo
>manipuation).
>http://codeascraft.etsy.com/2011/12/02/moving-from-svn-to-git-in-1000-easy
>-steps/
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Jeff King @ 2012-02-06 20:34 UTC (permalink / raw)
To: Nicholas Harteau; +Cc: git
In-Reply-To: <9D199309-85A6-42EE-9417-8C4E61534670@spotify.com>
On Mon, Feb 06, 2012 at 03:30:54PM -0500, Nicholas Harteau wrote:
> >>> ifdef NO_PERL_MAKEMAKER
> >>> -instdir_SQ = $(subst ','\'',$(prefix)/lib)
> >>> +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
> >
> > Isn't this a regression if I am a non-root user installing into
> > $HOME/local or similar? With MakeMaker, I end up with this in my
> > perl.mak:
> [...]
>
> Totally correct - let me re-think the non-root case. Thanks.
I just read the github PR you linked to. It sounds like it might work to
just add a knob that the homebrew recipe could tweak to enable this
behavior (with the knob off by default).
-Peff
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Nicholas Harteau @ 2012-02-06 20:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120206202610.GC30776@sigill.intra.peff.net>
On Feb 6, 2012, at 3:26 PM, Jeff King wrote:
> On Mon, Feb 06, 2012 at 02:38:20PM -0500, Nicholas Harteau wrote:
>
>>> perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
>>> is not present. perl can't "use Git;" in that scenario, as $prefix/lib
>>> isn't in perl's include path.
>>>
>>> This patch installs Git.pm into perl's 'installsitelib', generally
>>> $prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
>>> present, Git.pm gets installed in a location where 'use Git;' just
>>> works.
>> [...]
>>> ifdef NO_PERL_MAKEMAKER
>>> -instdir_SQ = $(subst ','\'',$(prefix)/lib)
>>> +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
>
> Isn't this a regression if I am a non-root user installing into
> $HOME/local or similar? With MakeMaker, I end up with this in my
> perl.mak:
>
> PREFIX = /home/peff/local
> ...
> SITEPREFIX = $(PREFIX)
> ...
> INSTALLSITELIB = $(SITEPREFIX)/share/perl/5.14.2
>
> which works great. Before your patch, without MakeMaker, git would
> install into /home/peff/local/lib, which is also OK. But with your
> patch, it will try:
>
> $ perl -V:installsitelib
> installsitelib='/usr/local/share/perl/5.14.2';
>
> which is not writable by me, and the install will fail.
>
> I know it's more convenient for some uses, because we know that
> installsitelib will be in perl's @INC. But git has always installed out
> of the box for non-root users, and I don't think we want to change that.
Totally correct - let me re-think the non-root case. Thanks.
--
Nicholas Harteau
nrh@spotify.com
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Jeff King @ 2012-02-06 20:26 UTC (permalink / raw)
To: Nicholas Harteau; +Cc: git
In-Reply-To: <7328033C-8A11-452D-A927-E81E2DC4ABD6@spotify.com>
On Mon, Feb 06, 2012 at 02:38:20PM -0500, Nicholas Harteau wrote:
> > perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
> > is not present. perl can't "use Git;" in that scenario, as $prefix/lib
> > isn't in perl's include path.
> >
> > This patch installs Git.pm into perl's 'installsitelib', generally
> > $prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
> > present, Git.pm gets installed in a location where 'use Git;' just
> > works.
> [...]
> > ifdef NO_PERL_MAKEMAKER
> > -instdir_SQ = $(subst ','\'',$(prefix)/lib)
> > +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
Isn't this a regression if I am a non-root user installing into
$HOME/local or similar? With MakeMaker, I end up with this in my
perl.mak:
PREFIX = /home/peff/local
...
SITEPREFIX = $(PREFIX)
...
INSTALLSITELIB = $(SITEPREFIX)/share/perl/5.14.2
which works great. Before your patch, without MakeMaker, git would
install into /home/peff/local/lib, which is also OK. But with your
patch, it will try:
$ perl -V:installsitelib
installsitelib='/usr/local/share/perl/5.14.2';
which is not writable by me, and the install will fail.
I know it's more convenient for some uses, because we know that
installsitelib will be in perl's @INC. But git has always installed out
of the box for non-root users, and I don't think we want to change that.
-Peff
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Johan Herland @ 2012-02-06 20:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Philip Oakley, git
In-Reply-To: <201202061814.58346.jnareb@gmail.com>
On Mon, Feb 6, 2012 at 18:14, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 6 Feb 2012, Johan Herland wrote:
>> On Mon, Feb 6, 2012 at 15:44, Jakub Narebski <jnareb@gmail.com> wrote:
>> > Relying on (default) hooks to implement this feature has the disadvantage
>> > that it wouldn't be turned on by default... while this feature would be
>> > most helpful for users new to git (scared by refuse to push).
>>
>> True. I too believe that this will be most helpful if it is enabled by
>> default. That said, the easiest way to get there might be through
>> first demonstrating that it works in practice when implemented as
>> hooks.
>
> Yes, starting with prototype implementation using existing infrastructure
> (hooks) would be a very good idea. (That's how first versions of what
> became submodules were implemented.)
>
> OTOH we should be aware of limitations of said prototype due to the fact
> that it is a prototype...
Agreed, but AFAICS (and modulo the addition of pre-rewrite and
pre/post-push hooks mentioned earlier) all of the things discussed so
far in this thread can be implemented as hooks.
>> > I am not sure either if everything (wrt. safety net) can be implemented
>> > via hooks. One thing that I forgot about is preventing rewinding of
>> > branch past the published commit using e.g. "git reset --hard <commit>".
>> > Unless `pre-rewrite` hook could be used for that safety too...
>>
>> Hmm. I don't think we'll be able to "plug" all the holes that might
>> leave the user in a rewritten state (e.g. what if the user (possibly
>> with the help of some tool) does an "echo $SHA1 >
>> .git/refs/head/master"?).
>
> First, I was thinking about having safety net against rewriting published
> commits being present only in porcelain. Plumbing would be not affected
> (perhaps there would be need to extend or add new plumbing to query "phase"
> state, though).
I also think this is very much a porcelain-only feature. I'd be more
worried if plumbing changes were needed.
>> And trying to plug too many holes might end
>> up annoying more experienced users who "know what they're doing".
>
> Second, forcing via command line parameter should always be an option.
Obviously, but if a large portion of the Git community felt the need
to always disable this feature, I'd say that we'd failed. The best
features are those that Just Work(tm).
>> Instead we might want to add a client-side check at push time. I
>> realize that this check is already done by the remote end, but the
>> client-side might be able to give a more helpful response along the
>> lines of:
>
> [...]
>
> Explanation is good, but the whole idea of rewriting safety is that you
> are informed (warned or denied) _before_ attempting rewrite and doing much
> work.
True, but there may be cases where the rewrite is not apparent until
after it has happened. E.g. a novice user may use 'git reset --hard'
in order to get to an earlier state for testing purposes, and then -
after completing the test - 'git reset --hard' back to the starting
point. I know this is not best practice, but is it bad enough that we
want to refuse it?
>> First, we don't need to annotate _all_ commits. For the 'public'
>> state, we only annotate the last/tip commit that was pushed/published.
>> From there, we can defer that all ancestor commits are also 'public'.
>
> Right.
>
>> For the 'secret' state, we do indeed annotate _all_ secret commits,
>> but I believe this will be a somewhat limited number of commits. If
>> your workflow forces you to annotate millions of commits as 'secret',
>> I claim there is something wrong with your workflow.
>
> Well, for the 'secret' we can rely on the fact that child of 'secret'
> commit must also be 'secret' (non-publishable) if secret is to stay
> secret. Still marking all 'secret' commits might be better idea from
> UI and from performance point of view.
I don't think we should automatically assume that all children of a
'secret' commit are also 'secret'. First of all, the git DAG was not
made for iterating forwards in history, so given a 'secret' commit, it
is computationally expensive to enumerate all its implied-'secret'
descendants. More importantly though, I don't agree with the premise.
I would typically use the 'secret' state as follows: While debugging a
piece of code, I might commit a few debug print statements, and I
would typically mark this debug commit as 'secret', in order to
prevent myself from accidentally pushing this. Although it probably
doesn't matter in practice, I think it is wrong for the commits made
(temporarily) on top of this debug commit to be also considered
'secret'. They are only unpublishable as a consequence of being based
on the debug commit, and only until I get around to rebasing away the
'secret' debug commit.
>> > Second, I have doubts if "phase" is really state of an individual commit,
>> > and not the feature of revision walking.
>
> It matters to presentation: can commit be simultaneously 'public' because
> of one branch, and 'draft' because of other.
>
>> I believe the 'public' state is a "feature of revision walking" (i.e.
>> one annotated 'public' commit implies that all its ancestors are also
>> 'public'). However, the 'secret' state should be bound to the
>> individual commit, IMHO.
>
> Good call, otherwise 'secret' commit could have been "side-leaked"
> by other refs being pushed.
>
> This means though that 'public' / 'draft' while looking similar to 'secret'
> are in fact a bit different things. In other words 'immutable' and
> 'impushable' traits are quite a bit different in behavior...
>
> Especially that one acts at pre-rewrite time, and second pre-push time.
Exactly. I find Mercurial 'phase' language confusing, precisely for
the reason that 'public' and 'secret' are DIFFERENT concepts. One
hinders rewrite and naturally applies to a commit AND its ancestors,
while the other hinders push and only applies to the commit itself.
The fact that they could be implemented by the same mechanisms (hooks
and notes) does not make them the same thing.
>> > Take for example the situation where given commit is reference by
>> > remote-tracking branch 'public/foo', and also by two local branches:
>> > 'foo' with upstream 'public/foo', and local branch 'bar' with no upstream.
>> >
>> > Now it is quite obvious that this feature should prevent rewriting 'foo'
>> > branch, for which commits are published upstream. But what about branch
>> > 'bar'? Should we prevent rewriting (e.g. rebase) here too? What about
>> > rewinding 'bar' to point somewhere else. What if 'bar' is really detached
>> > HEAD?
>> >
>> > These questions need to be answered...
>>
>> Good point. There are two questions we may need to answer: "Has commit
>> X ever been published?", and "Has commit X ever been published in the
>> context of branch Y?". In the latter case, we do indeed need to take
>> the upstream branch into account.
>
> I think the second one is more interested for rewrite safeties.
>
>> Basically, there are three different "levels" for this rewrite/publish
>> protection to run at:
>>
>> 1. Do not meddle at all. This is the current behavior, and assumes
>> that if the user rewrites and pushes something, the user knows what
>> he/she is doing, and Git should not meddle (obviously unless the
>> server refuses the push).
>
> I think that there should be some easy way to force such behavior,
> i.e. to discard rewrite safeties.
Indeed. We should probably have a simple config flag to enable the
rewrite protection. In fact I would argue that the flag should default
to false (disable protection) when unset, and then we should let
init/clone set the config flag to true (enable protection) in newly
created repos (unless explicitly disabled in the user/system configs).
This way, behavior does not change for existing repos, but new repos
are protected by default (with only a single command needed to disable
the protection).
>> 2. Warn/refuse rewriting commits in your upstream. This would only
>> check branch X against its registered upstream. Only if there is a
>> registered upstream, and you're about to rewrite commits that are
>> reachable from the upstream remote-tracking branch, should Git
>> intervene and warn/refuse the rewrite. This level would IMHO provide
>> most of the benefit, and little or no trouble (i.e. false positives).
>
> Right. I wonder if we can get usage statistics from Mercurial users
> about usage of their "phases" feature... though mapping terminology
> for example 'upstream' from Git to Mercurial and vice versa can be
> a pain, I guess.
I'm unsure how useful it would be. IMHO Git and Mercurial are
different enough (and promote sightly different workflows) that I
don't trust the the average Mercurial user's preference for
Mercurial's 'phase' behavior to be transferable to the average Git
user's preference for a similar behavior in Git.
>> 3. Warn/refuse rewriting _any_ 'public' commit. Refuse to rewrite any
>> commit that is reachable from any remote-tracking branch. Some would
>> say that this is a Good Thing(tm), since it prevents a commit from
>> being _copied_ (i.e. rebased or cherry-picked) between branches (you'd
>> be in this camp if you run a tightly-controlled workflow, where you
>> e.g. mandate upmerging patches from the oldest applicable branch
>> instead of cherry-picking patches from a newer branch). However, other
>> people would say that this is too limiting, and imposes unnecessary
>> rules on the workflow of the project (where e.g. copying (by way of
>> git-rebase) a topic branch from one place to another would cause an
>> annoying false positive).
>
> Well, we could always 'deny' on 2nd, and just 'warn' on 3rd...
Good idea.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Jeff King @ 2012-02-06 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, Andrew Ardill, git
In-Reply-To: <7vpqdr7rn0.fsf@alter.siamese.dyndns.org>
On Mon, Feb 06, 2012 at 10:17:55AM -0800, Junio C Hamano wrote:
> > PS I probably would have done it as:
> >
> > git init vendor
> > cd vendor
> > import import import
> > cd ..
> >
> > git init project
> > cd project
> > git fetch ../vendor master:vendor
> >
> > but I don't think there's anything wrong with your approach (in fact,
> > it's slightly more efficient).
>
> Probably I am slower than my usual slow self this morning. Does Michael's
> approach go like this:
>
> git init project
> cd project
> import import import
> git branch -m vendor
> git checkout -b master
>
> to fork from third-party codebase?
I thought it would have been:
git init project
cd project
git checkout -b vendor
import import import
git checkout -b master
modify modify modify
but he can probably say more.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] tag: die when listing missing or corrupt objects
From: Jeff King @ 2012-02-06 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Grennan, git, jasampler
In-Reply-To: <7vty337rug.fsf@alter.siamese.dyndns.org>
On Mon, Feb 06, 2012 at 10:13:27AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > OK, that's easy enough to do. Should we show lightweight tags to commits
> > for backwards compatibility (and just drop the parse_signature junk in
> > that case)? The showing of blobs or trees is the really bad thing, I
> > think.
>
> For now, dropping 3/3 and queuing this instead...
>
> ---
> Subject: tag: do not show non-tag contents with "-n"
Looks perfect. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] commit: remove commit.ignoreIntentToAdd, assume it's always true
From: Junio C Hamano @ 2012-02-06 20:05 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-5-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
> index 09b8bbf..7c7ab54 100755
> --- a/t/t2203-add-intent.sh
> +++ b/t/t2203-add-intent.sh
> @@ -50,7 +50,7 @@ test_expect_success 'can commit tree with i-t-a entry' '
> echo frotz >nitfol &&
> git add rezrov &&
> git add -N nitfol &&
> - git config commit.ignoreIntentToAdd true &&
> + git config commit.ignoreIntentToAdd false &&
This deserves a comment to the effect that the variable is now *ignored*.
> git commit -m initial &&
> git ls-tree -r HEAD >actual &&
> cat >expected <<EOF &&
^ permalink raw reply
* Re: [PATCH 3/4] commit: turn commit.ignoreIntentToAdd to true by default
From: Junio C Hamano @ 2012-02-06 20:03 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> - if (!set_commit_ignoreintenttoadd) {
Now no warning() is associated with testing of this flag, which means that
people who didn't get around to read the doc and react to the warnings in
the earlier releases will get _nothing_ when the real change hits them?
That sounds strangely bad. What am I missing?
> + if (!(cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)) {
> int i;
> for (i = 0; i < active_nr; i++)
> if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
> break;
> if (i < active_nr)
> warning(_("You are committing as-is with intent-to-add entries as the result of\n"
> - "\"git add -N\". Git currently forbids this case. This will change in\n"
> - "1.8.0 where intent-to-add entries are simply ignored when committing\n"
> - "as-is. Please look up document and set commit.ignoreIntentToAdd\n"
> - "properly to stop this warning."));
> + "\"git add -N\". Git currently forbids this case. But this is deprecated\n"
> + "support for this behavior will be dropped in FIXME.\n"
> + "Please look up document and set commit.ignoreIntentToAdd to true\n"
> + "or remove it."));
As this is marked with FIXME ;-)
At this point in the deprecation cycle, "currently forbids this case." is
not true at all. "You asked me to punt when you forgot to tell me the
final contents for i-t-a entries, so I am honoring your wish" is what is
happening here. Perhaps...
Git currently allows you to set commit.ignoreIntentToAdd to false
to remind you about the paths you may have forgotten to add the
real contents to before committing, but this support will be
removed in future versions of Git. Set commit.ignoreIntentToAdd
to `false` or remove the variable, and get used to the new
behaviour, to squelch this message.
^ permalink raw reply
* Re: [PATCH 1/4] cache-tree: update API to take abitrary flags
From: Junio C Hamano @ 2012-02-06 19:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> int cache_tree_update(struct cache_tree *it,
> struct cache_entry **cache,
> int entries,
> - int missing_ok,
> - int dryrun,
> - int silent)
> + int flags)
Very nice ;-)
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-06 19:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +commit.ignoreIntentToAdd::
> + Allow to commit the index as-is even if there are
> + intent-to-add entries (see option `-N` in linkgit:git-add[1])
> + in index. Set to `false` to disallow commit in this acase, or `true`
> + to allow it.
> ++
> +By default, `git commit` refuses to commit as-is when you have intent-to-add
> +entries. This will change in 1.8.0, where `git commit` allows it. If you
> +prefer current behavior, please set it to `false`.
s/acase/case/;
More importantly, if we allow it, what would be included and what would be
omitted from the final commit? What happens if we allow it is much more
important information than "we allow it even if there are".
When set to `true`, prevent `git commit` from creating a commit
from an index that has entries that were added with `git add -N`
but have not been updated with real contents, as the user may have
forgotten to tell the final contents for these entries. Setting
this to `false` makes `git commit` pretend as if these entries do
not exist in the index.
The default for this variable is `false`, but it will change to
`true` in later releases of git (perhaps 1.8.0). To ease the
transition, you may want to set it to `true` now and get used to
the new behaviour early, or you may want to set it to `false` to
keep the old behaviour a bit longer. We however expect to support
setting this to `false` (to keep the current behaviour) only for a
limited time after the default is changed to `true`.
Now, I removed the "intent to add" jargon from the above paragraph, the
description below can lose it as well.
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 9c1d395..ec548ea 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -123,8 +123,16 @@ subdirectories.
> Record only the fact that the path will be added later. An entry
> for the path is placed in the index with no content. This is
> useful for, among other things, showing the unstaged content of
> - such files with `git diff` and committing them with `git commit
> - -a`.
> + such files with `git diff`.
> ++
> +Paths added with this option have intent-to-add flag in index. The
> +flag is removed once real content is added or updated. By default you
> +cannot commit the index as-is from until this flag is removed from all
> +entries (i.e. all entries have real content). See commit.ignoreIntentToAdd
> +regardless the flag.
I cannot understand "regardlessthe flag" in the last sentence.
> ++
> +Committing with `git commit -a` or with selected paths works
> +regardless the config key and the flag.
Just an aside, not suggesting to change anything to the final text.
This is interesting in that the reason why "selected paths" works is a bit
subtle. You may have entries added with `-N` that are covered by the
pathspec, and those that are not covered by the pathspec. For the former
(i.e. those the user said "I'll decide the final contents later" but are
covered by pathspec), the user is telling the final contents to be in the
commit, so we know the final contents for them. For the latter (i.e.
those outside the pathspec), they are excluded and made to match the
version in the HEAD commit, so we know the final contents for them, too.
> + if (i < active_nr)
> + warning(_("You are committing as-is with intent-to-add entries as the result of\n"
> + "\"git add -N\". Git currently forbids this case.
Can we phrase this a bit better?
It is not like "forbids", but is "giving up because you didn't tell me
what content to include in the commit, even though you said you will tell
me later".
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Nicholas Harteau @ 2012-02-06 19:38 UTC (permalink / raw)
To: git
In-Reply-To: <24482D02-B773-4FE3-8FC7-92B8B4D8C0FA@spotify.com>
This is a boring patch, I know, but it affects anyone doing a vanilla git installation on an os that bundles perl but not ExtUtils::MakeMaker, which is quite common. Git's own utilities in perl can use Git.pm, but any other perl programs will fail to 'use Git;'
Any takers?
On Jan 30, 2012, at 11:51 AM, Nicholas Harteau wrote:
> perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
> is not present. perl can't "use Git;" in that scenario, as $prefix/lib
> isn't in perl's include path.
>
> This patch installs Git.pm into perl's 'installsitelib', generally
> $prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
> present, Git.pm gets installed in a location where 'use Git;' just
> works.
>
> for some additional discussion, see:
> https://github.com/mxcl/homebrew/pull/8643
> https://github.com/mxcl/homebrew/issues/8620
> ---
> perl/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index b2977cd..2199eb1 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -21,7 +21,7 @@ clean:
> $(RM) $(makfile).old
>
> ifdef NO_PERL_MAKEMAKER
> -instdir_SQ = $(subst ','\'',$(prefix)/lib)
> +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
> $(makfile): ../GIT-CFLAGS Makefile
> echo all: private-Error.pm Git.pm > $@
> echo ' mkdir -p blib/lib' >> $@
> --
> 1.7.8.3
>
> --
> nicholas harteau
> nrh@spotify.com
>
>
>
>
--
nicholas harteau
nrh@spotify.com
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: demerphq @ 2012-02-06 18:39 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Jeff King, Junio C Hamano, git, Michael Haggerty
In-Reply-To: <CAH5451ndjozo8-Cx3+Vc84TCjKJvCnSuOUsQS5cnqXsdc=8fMQ@mail.gmail.com>
On 6 February 2012 05:42, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 6 February 2012 15:30, Jeff King <peff@peff.net> wrote:
>
>> And perhaps in that case we should be discouraging them from calling it
>> something besides master (because while master is mostly convention,
>> there are a few magic spots in the code where it is treated specially,
>> and departing from the convention for no good reason should be
>> discouraged).
>
> What exactly are the areas where 'master' is treated specially? I
> agree that people should be discouraged from needlessly abandoning
> convention, however I think users should have the ability to name
> their branches as they see fit.
FWIW, we at $work have used a repo without a master branch at all
since the very beginning and never noticed a problem with it.
Although we *did* rename the original master to "trunk".
We did this because we felt that in a scenario where there is a
designated central "master repo" that the use of "master branch" would
get really confusing, so we have a master repo, whos main branch is
"trunk".
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-02-06 18:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jeff King, git
In-Reply-To: <4F2F9661.2020606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
>> So we are breaking the equivalence between these three only when HEAD
>> points at an unborn branch.
>
> You are thinking too much like a developer and not like a user. For a user,
>
> git checkout -b foo
>
> is a short-hand for
>
> "create and check out a branch at my current state"
>
> and the interpretation of what that means when I am on an unborn branch
> seems unambiguous.
Ok, that is a very good explanation.
Care to come up with a patch to Documentation/git-checkout.txt? The
description there strongly implies that <start point> is an existing
commit. Not much is said about what the lack of <start point> mean when
it describes "checkout -b", and a standalone description of <start point>
says "The name of a comit at which to start... Defaults to HEAD". These
need to be loosened and described in terms of the closer-to-the-user "at
my current state".
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-02-06 18:17 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, Andrew Ardill, git
In-Reply-To: <20120206085707.GA24149@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> PS I probably would have done it as:
>
> git init vendor
> cd vendor
> import import import
> cd ..
>
> git init project
> cd project
> git fetch ../vendor master:vendor
>
> but I don't think there's anything wrong with your approach (in fact,
> it's slightly more efficient).
Probably I am slower than my usual slow self this morning. Does Michael's
approach go like this:
git init project
cd project
import import import
git branch -m vendor
git checkout -b master
to fork from third-party codebase?
Or Michael had his own 'master' already and wanted an independent orphaned
history from vendor, perhaps like this?
git init project
cd project
work work work
git checkout --orphan vendor
: perhaps "git clean -f" here???
import import import
git checkout master
: rootless merge???
git merge vendor
^ permalink raw reply
* Re: [PATCH 2/3] tag: die when listing missing or corrupt objects
From: Junio C Hamano @ 2012-02-06 18:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Tom Grennan, git, jasampler
In-Reply-To: <20120206083832.GA9425@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> OK, that's easy enough to do. Should we show lightweight tags to commits
> for backwards compatibility (and just drop the parse_signature junk in
> that case)? The showing of blobs or trees is the really bad thing, I
> think.
For now, dropping 3/3 and queuing this instead...
---
Subject: tag: do not show non-tag contents with "-n"
"git tag -n" did not check the type of the object it is reading the top n
lines from. At least, avoid showing the beginning of trees and blobs when
dealing with lightweight tags that point at them.
As the payload of a tag and a commit look similar in that they both start
with a header block, which is skipped for the purpose of "-n" output,
followed by human readable text, allow the message of commit objects to be
shown just like the contents of tag objects. This avoids regression for
people who have been using "tag -n" to show the log messages of commits
that are pointed at by lightweight tags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/tag.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 1e27f5c..6d6ae88 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -95,19 +95,20 @@ static void show_tag_lines(const unsigned char *sha1, int lines)
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
die_errno("unable to read object %s", sha1_to_hex(sha1));
- if (!size) {
- free(buf);
- return;
- }
+ if (type != OBJ_COMMIT || type != OBJ_TAG)
+ goto free_return;
+ if (!size)
+ die("an empty %s object %s?",
+ typename(type), sha1_to_hex(sha1));
/* skip header */
sp = strstr(buf, "\n\n");
- if (!sp) {
- free(buf);
- return;
- }
- /* only take up to "lines" lines, and strip the signature */
- size = parse_signature(buf, size);
+ if (!sp)
+ goto free_return;
+
+ /* only take up to "lines" lines, and strip the signature from a tag */
+ if (type == OBJ_TAG)
+ size = parse_signature(buf, size);
for (i = 0, sp += 2; i < lines && sp < buf + size; i++) {
if (i)
printf("\n ");
@@ -118,6 +119,7 @@ static void show_tag_lines(const unsigned char *sha1, int lines)
break;
sp = eol + 1;
}
+free_return:
free(buf);
}
^ permalink raw reply related
* Re: [PATCH 2/3] tag: die when listing missing or corrupt objects
From: Junio C Hamano @ 2012-02-06 18:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Tom Grennan, git, jasampler
In-Reply-To: <20120206083832.GA9425@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> OK, that's easy enough to do. Should we show lightweight tags to commits
> for backwards compatibility (and just drop the parse_signature junk in
> that case)? The showing of blobs or trees is the really bad thing, I
> think.
I think that is a sensible thing to do. I see many end-user documents on
the Interweb that uses lightweight "git tag", and I do not think they are
shooting for brevity of their illustration. The authors of these pages do
primarily use lightweight tags because they do not have anything more to
add in the message more than the log message commit objects they point at.
And it is a huge regression if we stop showing them if they are used to
use "tag -n".
^ permalink raw reply
* Re: [PATCH v5 00/12] Column display
From: Junio C Hamano @ 2012-02-06 17:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1328371156-4009-1-git-send-email-pclouds@gmail.com>
I've added two patches on top of this series and queued on 'pu'.
The first one is a fix for style issues; this is limited to absolute
minimum and I wouldn't be surprised if I fixed one instance of the same
class of style violations just as an example while ignoring bunch of
similar ones.
The second was to see how "git branch" behaves when it sees one absurdly
long entry (longer than $COLUMN width) among the normal ones, primarily
done just for fun.
You may want to tease the first one apart and squash them in to where the
problem originates. The second one is optional, but as you hinted an
interest on coming up with a heuristic to cram more info by making some
oddball entries span multi-column, it might serve as a good starting point
to think about the possible issues.
Thanks for an amusing read.
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Phil Hord @ 2012-02-06 17:31 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Leif Gruenwoldt, git
In-Reply-To: <4F29BEB7.1080901@web.de>
On Wed, Feb 1, 2012 at 5:37 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 31.01.2012 23:50, schrieb Phil Hord:
>> What I mean is that a developer may be completely focused on one
>> particular submodule (his domain). He does his work in this module,
>> and when it's ready he commits and pushes to the server. 'git status'
>> shows him that his directory is clean. But this is only because he
>> doesn't really know where the submodules top-directories are, so he
>> doesn't realize that he has changes in another submodule that he has
>> not committed. He has to know to run 'git status' from somewhere in
>> the superproject (ostensibly in the root directory of that
>> superproject). But he may forget since 'git status' already assured
>> him he was done.
> <snip>
>> I guess what would help here is something like the opposite of 'git
>> status' showing the status of descendant submodules; it would help if
>> it showed the status of sibling submodules and the superproject as
>> well.
>
> Hmm, I really think the fact that submodules are unaware that they
> are part of a superproject is a feature. I'd prefer seeing that kind
> of problem being tackled by the CI server and/or user education. Or
> maybe a pre-commit hook which issues a warning in that case?
I agree that submodule isolation is a feature essential to the
architecture of git and the submodules implementation. But it is also
a limitation, not just of this example. A pre-commit hook is a nice
idea, but it doesn't help 'git status' (which is the standard go-to
answer point for "where am I").
This has me thinking more about recursing siblings now, though. I find
myself typing something like this quite a lot:
git submodule foreach 'git grep "someFunction" || :'
Or worse (in that the UI is more unwieldy):
git submodule foreach 'git log --oneline "-SsomeFunction" || :'
But what I want is this:
git --git-dir=${TOP}/../.git grep --recurse-submodules "someFunction"
But not really, because I am lazy and that is too much typing.
git grep --include-siblings "someFunction"
Maybe I can add a "sib" macro to get this:
git sib grep "someFunction"
But now I've really wandered off-topic.
Phil
^ permalink raw reply
* Re: [PATCH v5 09/12] branch: add --column
From: Junio C Hamano @ 2012-02-06 17:31 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1328371156-4009-10-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +test_expect_success 'git branch -v with column.ui ignored' '
> + git config column.ui column &&
> + COLUMNS=80 git branch -v | cut -c -10 >actual &&
> + git config --unset column.ui &&
> + cat >expected <<\EOF &&
> + a/b/c
> + abc
> + bam
> + bar
> + foo
> + j/k
> + l
> + m/m
> +* master
> + master2
> + n
> + o/o
> + o/p
> + q
> + r
> +EOF
For a test like these where you expect whitespaces at the end, please make
sure that these whitespaces are visible to people who read test scripts,
by doing something like this instead:
sed -e 's/#$//' >expected <<\EOF
a/b/c #
abc #
bam #
bar #
foo #
EOF
Thanks.
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Jakub Narebski @ 2012-02-06 17:14 UTC (permalink / raw)
To: Johan Herland; +Cc: Philip Oakley, git
In-Reply-To: <CALKQrgcN9Miq7SN_ETvjboRkHRFzcZejrQfy36BQFxYDnVPP6w@mail.gmail.com>
On Mon, 6 Feb 2012, Johan Herland wrote:
> On Mon, Feb 6, 2012 at 15:44, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sun, 5 Feb 2012, Johan Herland wrote:
> > Relying on (default) hooks to implement this feature has the disadvantage
> > that it wouldn't be turned on by default... while this feature would be
> > most helpful for users new to git (scared by refuse to push).
>
> True. I too believe that this will be most helpful if it is enabled by
> default. That said, the easiest way to get there might be through
> first demonstrating that it works in practice when implemented as
> hooks.
Yes, starting with prototype implementation using existing infrastructure
(hooks) would be a very good idea. (That's how first versions of what
became submodules were implemented.)
OTOH we should be aware of limitations of said prototype due to the fact
that it is a prototype...
> > I am not sure either if everything (wrt. safety net) can be implemented
> > via hooks. One thing that I forgot about is preventing rewinding of
> > branch past the published commit using e.g. "git reset --hard <commit>".
> > Unless `pre-rewrite` hook could be used for that safety too...
>
> Hmm. I don't think we'll be able to "plug" all the holes that might
> leave the user in a rewritten state (e.g. what if the user (possibly
> with the help of some tool) does an "echo $SHA1 >
> .git/refs/head/master"?).
First, I was thinking about having safety net against rewriting published
commits being present only in porcelain. Plumbing would be not affected
(perhaps there would be need to extend or add new plumbing to query "phase"
state, though).
> And trying to plug too many holes might end
> up annoying more experienced users who "know what they're doing".
Second, forcing via command line parameter should always be an option.
> Instead we might want to add a client-side check at push time. I
> realize that this check is already done by the remote end, but the
> client-side might be able to give a more helpful response along the
> lines of:
[...]
Explanation is good, but the whole idea of rewriting safety is that you
are informed (warned or denied) _before_ attempting rewrite and doing much
work.
> > > If you use 'git notes' to annotate 'public' and 'secret' states, then
> > > you can also use the --show-notes=<ref> option to let show/log display
> > > the annotations on 'public'/'secret' commits.
> >
> > First, in my opinion annotating _all_ commits with their phase is I think
> > out of question, especially annotating 'public' commits. I don't think
> > git-notes mechanism would scale well to annotating every commit; but
> > perhaps this was tested to work, and I am mistaken.
>
> First, we don't need to annotate _all_ commits. For the 'public'
> state, we only annotate the last/tip commit that was pushed/published.
> From there, we can defer that all ancestor commits are also 'public'.
Right.
> For the 'secret' state, we do indeed annotate _all_ secret commits,
> but I believe this will be a somewhat limited number of commits. If
> your workflow forces you to annotate millions of commits as 'secret',
> I claim there is something wrong with your workflow.
Well, for the 'secret' we can rely on the fact that child of 'secret'
commit must also be 'secret' (non-publishable) if secret is to stay
secret. Still marking all 'secret' commits might be better idea from
UI and from performance point of view.
> Second, git-notes were indeed designed scale well to handle a large
> number of notes, up to the same order of magnitude as the number of
> commits in your repo. (When git-notes was originally written, I
> successfully tested it on versions of a linux-kernel repo where every
> single commit was annotated).
Ah. That is very nice!
> In this case, the number of 'public'
> annotations in your repo would be equal to the number of pushes you
> do, and the number of 'secret' annotations would be equal to the
> number of 'secret' commits in your repo. I'd expect both of these
> numbers to be orders of magnitude smaller than the total number of
> commits in your repo (given a fairly typical workflow in a fairly
> typical repo).
Right.
> > Second, I have doubts if "phase" is really state of an individual commit,
> > and not the feature of revision walking.
It matters to presentation: can commit be simultaneously 'public' because
of one branch, and 'draft' because of other.
> I believe the 'public' state is a "feature of revision walking" (i.e.
> one annotated 'public' commit implies that all its ancestors are also
> 'public'). However, the 'secret' state should be bound to the
> individual commit, IMHO.
Good call, otherwise 'secret' commit could have been "side-leaked"
by other refs being pushed.
This means though that 'public' / 'draft' while looking similar to 'secret'
are in fact a bit different things. In other words 'immutable' and
'impushable' traits are quite a bit different in behavior...
Especially that one acts at pre-rewrite time, and second pre-push time.
> > Take for example the situation where given commit is reference by
> > remote-tracking branch 'public/foo', and also by two local branches:
> > 'foo' with upstream 'public/foo', and local branch 'bar' with no upstream.
> >
> > Now it is quite obvious that this feature should prevent rewriting 'foo'
> > branch, for which commits are published upstream. But what about branch
> > 'bar'? Should we prevent rewriting (e.g. rebase) here too? What about
> > rewinding 'bar' to point somewhere else. What if 'bar' is really detached
> > HEAD?
> >
> > These questions need to be answered...
>
> Good point. There are two questions we may need to answer: "Has commit
> X ever been published?", and "Has commit X ever been published in the
> context of branch Y?". In the latter case, we do indeed need to take
> the upstream branch into account.
I think the second one is more interested for rewrite safeties.
> Basically, there are three different "levels" for this rewrite/publish
> protection to run at:
>
> 1. Do not meddle at all. This is the current behavior, and assumes
> that if the user rewrites and pushes something, the user knows what
> he/she is doing, and Git should not meddle (obviously unless the
> server refuses the push).
I think that there should be some easy way to force such behavior,
i.e. to discard rewrite safeties.
> 2. Warn/refuse rewriting commits in your upstream. This would only
> check branch X against its registered upstream. Only if there is a
> registered upstream, and you're about to rewrite commits that are
> reachable from the upstream remote-tracking branch, should Git
> intervene and warn/refuse the rewrite. This level would IMHO provide
> most of the benefit, and little or no trouble (i.e. false positives).
Right. I wonder if we can get usage statistics from Mercurial users
about usage of their "phases" feature... though mapping terminology
for example 'upstream' from Git to Mercurial and vice versa can be
a pain, I guess.
> 3. Warn/refuse rewriting _any_ 'public' commit. Refuse to rewrite any
> commit that is reachable from any remote-tracking branch. Some would
> say that this is a Good Thing(tm), since it prevents a commit from
> being _copied_ (i.e. rebased or cherry-picked) between branches (you'd
> be in this camp if you run a tightly-controlled workflow, where you
> e.g. mandate upmerging patches from the oldest applicable branch
> instead of cherry-picking patches from a newer branch). However, other
> people would say that this is too limiting, and imposes unnecessary
> rules on the workflow of the project (where e.g. copying (by way of
> git-rebase) a topic branch from one place to another would cause an
> annoying false positive).
Well, we could always 'deny' on 2nd, and just 'warn' on 3rd...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] bash-completion: add --edit-description to choices for branch
From: Paul Gortmaker @ 2012-02-06 17:03 UTC (permalink / raw)
To: git; +Cc: Paul Gortmaker
Support was recently added to allow storing a branch description,
so teach bash completion about it.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 78be195..a2965f7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1152,7 +1152,7 @@ _git_branch ()
__gitcomp "
--color --no-color --verbose --abbrev= --no-abbrev
--track --no-track --contains --merged --no-merged
- --set-upstream
+ --set-upstream --edit-description
"
;;
*)
--
1.7.9
^ permalink raw reply related
* Re: git-gui Ctrl-U (unstage) broken
From: Stefan Haller @ 2012-02-06 16:48 UTC (permalink / raw)
To: Pat Thoyts, Victor Engmark; +Cc: git
In-Reply-To: <877h0at7ua.fsf@fox.patthoyts.tk>
Pat Thoyts <patthoyts@users.sourceforge.net> wrote:
> Victor Engmark <victor.engmark@gmail.com> writes:
>
> >Using the git-gui available with the default Ubuntu 10.10 repos, I'm
> >not able to unstage files with the default keyboard shortcut. To
> >reproduce:
> >1. Change a file in the repository
> >2. Run `git gui`
> >3. Stage the changed file
> >4. Select the changed file in the "Staged Changes (Will Commit)" list
> >5. Click Ctrl-U
> >
> >Expected outcome: The selected file should be unstaged.
> >
> >Actual outcome: Nothing at all changes in the GUI.
>
> I checked this with the current version (gitgui-0.16.0) and it works ok
> for me (on windows) - ie: ctrl-u unstaged a selected file.
Pat, it depends on where the focus is when you press ctrl-u. If you
click in the diff pane, and then select the file to unstage, and then
press ctrl-u, then nothing happens. If you click in the commit message
field, then ctrl-u works fine.
The same problem exists with ctrl-j for "Revert Changes". In that case
it is caused by the vi bindings that were introduced by 60aa065f69. It
seems that a binding for <Key-j> is also triggered by ctrl-j (if you
have a long diff you can see the diff pane scroll down by one line).
I'm not sure how to explain why ctrl-u doesn't work though, as I can't
see any binding for <Key-u>, but maybe this gives a clue to someone who
knows more about TCL than I do.
(It's not Windows-specific, btw: the same problem exists on Mac with
Command-U and Command-J.)
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ 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