* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
Aside, previous discussion -
http://thread.gmane.org/gmane.comp.version-control.git/150559
Sadly, it seems to have petered out, it looks to me like a case of
perfect being the enemy of the good. I'm really just trying to make it
good enough that we can move new-workdir out of contrib. It's a
valuable tool, we just need to remove some of its sharper edges.
j.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Andreas Krey @ 2011-10-05 20:00 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>
On Wed, 05 Oct 2011 15:11:30 +0000, Jay Soffian wrote:
...
> > - Error out (or warn if forced) upon any attempt to update the tip of a
> > branch that is checked out in more than one place; and
>
> I think that's a worse user experience. "Sorry, can't commit your
> changes because you've checked out this branch elsewhere."
This is actually pretty much the same as "you can't push into the
currently checked-out branch".
I do come from CVS where multiple checkouts of the same branch are obviously
common, but the semantics are different. git would need to allow to be in
a detached state but still have a notion of a 'current' branch to mimic that;
this tentative 'current' branch being what we need to merge or rebase onto later.
Just thinking.
It may actually be logical to put the other workdirs into detached state when
the branch they are on is committed into; however, this is seriously confusing.
> Now the
> user's choices are:
>
> 1. commit --force (and thus confusing the other workdirs)
> 2. checkout -b new_branch && commit
>
> Both of which I think are worse than preventing the checkout in the first place.
Hmm. You mean forcing the user to make a new branch *earlier* than at
commit time is better?
Andreas
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-05 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vvcs370d1.fsf@alter.siamese.dyndns.org>
On 05/10/2011 20:35, Junio C Hamano wrote:
>> What if I do not want to say things about the "content" of the
>> directory but about the directory itself? This is exactly my case.
>
> Oh, that is totally different. We do not store directories, and they do
> not have attributes, period.
While that is true (yet many beg git to natively support empty dirs…),
`.gitignore` does deal with directories. As you quoted,
> If the pattern ends with a slash, it is removed for the purpose
> of the following description, but it would only find a match with
> a directory. In other words, foo/ will match a directory foo and
> paths underneath it
Isn't applying the same logic to `.gitattributes` be the most
straightforward solution? Also code-wise, I suppose.
Bye,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Junio C Hamano @ 2011-10-05 20:25 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: Michael Haggerty, git
In-Reply-To: <4E8CBB4C.4000408@svario.it>
Gioele Barabucci <gioele@svario.it> writes:
> ... As you quoted,
>
>> If the pattern ends with a slash, it is removed for the purpose
>> of the following description, but it would only find a match with
>> a directory. In other words, foo/ will match a directory foo and
>> paths underneath it
But the "will match a directory foo and" part in that description, while
makes it easier to read, is technically unnecessary and even misleading.
The ignore patterns ultimately decides which paths are not to be added to
the index. Colloquially we could say "foo directory is ignored", but such
a statement is just a short-hand for "everything in foo is ignored";
technically "foo directory is ignored" is not necessary because we never
add the directory itself to the index.
^ permalink raw reply
* Re: [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Junio C Hamano @ 2011-10-05 20:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Michael Haggerty, git
In-Reply-To: <201110052111.52701.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>> > Previously, get_sha1_hex() would read one character past the end of a
>> > null-terminated string whose strlen was an even number less than 40.
>> > Although the function correctly returned -1 in these cases, the extra
>> > memory access might have been to uninitialized (or even, conceivably,
>> > unallocated) memory.
>> >
>> > Add a check to avoid reading past the end of a string.
>>
>> Makes sense; thanks.
>
> Has this fixed patch ever made it to pu? I'm still seeing the same
> breakage in the automated valgrind runs.
I do not think so.
I was under the impression that Michael wanted to include this in the
early part of a re-roll of check-ref-format series.
I'll do the rebase myself. Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 20:50 UTC (permalink / raw)
To: Andreas Krey; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20111005200043.GA32732@inner.h.iocl.org>
On Wed, Oct 5, 2011 at 4:00 PM, Andreas Krey <a.krey@gmx.de> wrote:
> Hmm. You mean forcing the user to make a new branch *earlier* than at
> commit time is better?
In my mind, we're trying to make new-workdir usable for non-advanced
users. I think it's conceptually simplest to allow a branch to be
checked out only once.
FWIW, I use a modified copy of new-workdir w/this usage:
git new-workdir <repo> <workdir> <ref> [<start>]
Which allows me to create a new branch and workdir checked out to the
new branch in one shot. It refuses to create the <workdir> if <ref>
resolves to a checked-out branch. (If I want to start detached I can
do so with <ref>^0, but I rarely if ever do that.)
j.
^ permalink raw reply
* [ANNOUNCE] libgit2 v0.15.0
From: Vicent Marti @ 2011-10-05 21:00 UTC (permalink / raw)
To: libgit2, git, git-dev
Hello everyone,
another minor libgit2 release is here. This time with proper
networking support, even on Windows/MSVC.
The release has been tagged at:
https://github.com/libgit2/libgit2/tree/v0.15.0
A dist package can be found at:
https://github.com/downloads/libgit2/libgit2/libgit2-0.15.0.tar.gz
Updated documentation can be found at:
http://libgit2.github.com/libgit2/
The full change log follows after the message.
Cheers,
Vicent
================
libgit2 v0.15.0 "Das Wunderbar Release"
I am aware the codename is not gramatically correct in any language.
Check the COPYING file for the detailed terms on libgit2's license. Check
the AUTHORS file for the full list of guilty parties.
As we slowly stabilize the API, we've dropped 1 function from the library,
and changed the signature of only 5 of them.
In this release of libgit2:
* `git_blob_rawsize`: Now returns `size_t` instead of int, allowing
files >4GB in 64 bit systems.
- `git_commit_message_short`: Please use `git_commit_message`
to get the full message and decide which is the "short view" according
to your needs (first line, first 80 chars...)
+ `git_commit_message_encoding`: Returns the encoding field of a commit
message, if it exists.
* `git_commit_create`, `git_commit_create_v`: New argument `encoding`, which
adds a encoding field to the generated commit object.
+ `git_config_find_system`: Returns the path to the system's global config
file (according to the Core Git standards).
* `git_config_get_XX`, `git_config_set_XX`: the `long` and `int` types have
been replaced by `int64` and `int32` respectively, to make their meaning more
obvious.
+ `git_indexer`: An interface to index Git Packfiles has been added in the
`git2/indexer.h` header.
* `git_reflog_entry_XX`: Reflog entries are now returned as `git_oid *` objects
instead of hexadecimal OIDs.
+ `git_remote`: More fetch functionality has been added to the `git2/remote.h`
functionality. Local, Smart HTTP and Git protocols are now supported.
+ `git_repository_head`: Returns the HEAD of the repository.
+ `git_repository_config_autoload`: Opens the configuration file of a
repository,
including the user's and the system's global config files, if they
can be found.
* `git_signature_now`: Now returns an error code; the signature is stored by
reference.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 21:29 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Also, while I might recommend new-workdir to my coworkers with the
> advice "don't checkout the same branch in multiple workdirs", never in
> a million years would I say "use new-workdir, but make sure to only
> use a detached HEAD in the workdirs." The latter would make their
> actual HEADs explode. :-)
>
>> ...
>> Because you forgot that the high level operation "branch renaming" needs
>> to be aware of that "this branch is checked out elsewhere" information,
>> you allowed it to break the workdir. If you hooked into lower level
>> machinery that is shared, you wouldn't have caused this breakage.
>> Similarly, if delete_ref() were taught about the new requirement, you
>> would have covered both "branch -d" and "update-ref -d".
>
> I did not forget, I just hadn't gotten there yet while this was still
> an RFC/PATCH.
You conveniently also forgot that you also said:
> Aside, there's nothing wrong with renaming a checked out branch.
With that lack of understanding, it wasn't "hadn't gotten there", but was
actually "didn't even know it was needed".
But that is OK. We have discussions to find out what we missed by learning
from others' insights.
> Another issue to resolve is what happens when the workdir or repo are
> moved in the filesystem. And making prune aware of HEAD reflogs in the
> alternate workdirs.
>
>> I do not necessarily think that it is a good approach to forbid the same
>> branch to be checked out in two different places, by the way. One reason
>> people would want to keep multiple workdirs is so that while they are
>> still working on a branch and are not yet at a good "stop point" to even
>> make a temporary commit to get interrupted, they find it sometimes
>> necessary to be able to build the tip of that same branch and even make a
>> small in-working-tree fixes (which later will be carried back to the
>> primary branch). The problem arises only when one of the repositories try
>> to update or delete the branch while it is checked out in another working
>> tree.
>
> That is not at all my experience of how workdirs are used.
I am afraid to say, with that statement, that your knowledge about the way
the tool can be used is not wide enough to judge if one policy restriction
(e.g. "never check out the same branch in multiple places") is general
enough to add to the tool. I do not claim mine is good enough, but I at
least know better than proposing a rule that may be too restictive to
negatively affect other people's workflows.
I always maintain four workdirs that I can use to build the tip of four
integration branches while I work on other things in the primary branch,
plus another that has a detached HEAD so that I can "reset --hard" around
without having to worry about what I do there would negatively affect what
I do elsewhere or vice versa. Of course, updating 'master' in my primary
repository will require the "build master" workdir to be "reset --hard"
before it is used, and that is part of my workflow already. I consider it
is one of "people learned to work around the restriction of the tool so
well already that they may not realize it" we discussed earlier.
Also, if your goal is to give a different semantics, like:
> In my mind, we're trying to make new-workdir usable for non-advanced
> users. I think it's conceptually simplest to allow a branch to be
> checked out only once.
you would really need to make sure that your changes would not harm other
users of the same tool that you are not targetting for, and also the
changes to the core part of the system that needs your specialized policy
makes sense in the wider context. The former you can claim "the policy
does not kick in when configuration is not set", but that is weak if the
policy is too ad-hoc and not well thought out. I actually care about the
latter more, as it is not worth having to spend maintenance effort to
carry changes that only stop some but not other kind of mistakes in the
core part to be more widely applicable.
^ permalink raw reply
* 66 patches and counting
From: Michael Haggerty @ 2011-10-05 21:29 UTC (permalink / raw)
To: git
My renovation of refs.c [1] is currently at 66 patches and counting.
What can I say?: (1) I like to make changes in the smallest irreducible
steps and (2) there is a lot that needed to be done in refs.c.
When I'm done, is it OK to dump a patch series like that on the git
mailing list? Is it pointless because nobody will review them anyway?
Is a big pile of changes like this welcome in any form? Would it be
better to convey the changes via git itself (e.g., github) rather than
via emails?
Michael
[1] hierarchical-refs at git://github.com/mhagger/git.git
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jonathan Nieder @ 2011-10-05 21:30 UTC (permalink / raw)
To: Jay Soffian; +Cc: Andreas Krey, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_DynQ8U6T9YMsWstKF_Cf6CSCr8b8E4T=p5uyGPh28G=kA@mail.gmail.com>
Jay Soffian wrote:
> In my mind, we're trying to make new-workdir usable for non-advanced
> users.
I'd be happy already with making it comfortable for the advanced
users. :)
I think your patch goes in a right direction (using the shared
.git/config file as a way to negotiate ownership of branches).
Junio’s comments about it seeming sensible to
- make this apply to other operations that clobber a branch
- make the “[branch "master"] checkedout” configuration multi-valued
if there is to be support for "git checkout -f" overriding this at
all
ring true to me. Making the value of this variable the path to the
.git dir or worktree (rather than an opaque string) seems like a very
good thing: it means that a future git could check if the directory
still exists and break the lock if someone has used “rm -fr”.
As for moving “git new-workdir” out of contrib, I believe another
prerequisite is sharing the HEAD reflog.
Just my two cents,
Jonathan
^ permalink raw reply
* Re: 66 patches and counting
From: Junio C Hamano @ 2011-10-05 21:36 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4E8CCC55.9070408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> When I'm done, is it OK to dump a patch series like that on the git
> mailing list?
Bits and pieces that are of digestable sizes.
I would wait sending anything large-ish (like more than 10 patches) before
'next' is rewound, which is the sign the cycle is in full swing.
> Is it pointless because nobody will review them anyway?
Bits and pieces that are of digestable sizes. Especially given:
> I like to make changes in the smallest irreducible steps
each step in your series should make sense by itself already (otherwise
you would have rebase-i'ed them to collapse too-small pieces into one that
makes sense standalone on top of the earlier steps).
> Is a big pile of changes like this welcome in any form?
Bits and pieces that are of digestable sizes.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vy5wz5dql.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 5:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I am afraid to say, with that statement, that your knowledge about the way
> the tool can be used is not wide enough to judge if one policy restriction
> (e.g. "never check out the same branch in multiple places") is general
> enough to add to the tool. I do not claim mine is good enough, but I at
> least know better than proposing a rule that may be too restictive to
> negatively affect other people's workflows.
>
> I always maintain four workdirs that I can use to build the tip of four
> integration branches while I work on other things in the primary branch,
> plus another that has a detached HEAD so that I can "reset --hard" around
> without having to worry about what I do there would negatively affect what
> I do elsewhere or vice versa. Of course, updating 'master' in my primary
> repository will require the "build master" workdir to be "reset --hard"
> before it is used, and that is part of my workflow already. I consider it
> is one of "people learned to work around the restriction of the tool so
> well already that they may not realize it" we discussed earlier.
Is it a regression to your workflow that you have to now use "checkout
-f" instead of "checkout" to checkout the same branch in more than one
location?
> Also, if your goal is to give a different semantics, like:
>
>> In my mind, we're trying to make new-workdir usable for non-advanced
>> users. I think it's conceptually simplest to allow a branch to be
>> checked out only once.
>
> you would really need to make sure that your changes would not harm other
> users of the same tool that you are not targetting for, and also the
> changes to the core part of the system that needs your specialized policy
> makes sense in the wider context. The former you can claim "the policy
> does not kick in when configuration is not set", but that is weak if the
> policy is too ad-hoc and not well thought out. I actually care about the
> latter more, as it is not worth having to spend maintenance effort to
> carry changes that only stop some but not other kind of mistakes in the
> core part to be more widely applicable.
Perhaps:
core.multipleCheckouts = {true,false}
- false prevents multiple checkouts without -f
advice.multipleCheckouts = {true,false}
- false disables multiple-checkout notice
And when there are multiple checkouts, warn on committing about other
workdirs that now need reset --hard.
j.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 21:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andreas Krey, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20111005213002.GA12667@elie>
On Wed, Oct 5, 2011 at 5:30 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> As for moving “git new-workdir” out of contrib, I believe another
> prerequisite is sharing the HEAD reflog.
I don't understand this. Is it about not gc'ing commits that other
workdirs are detached on, or something more?
I like that each of my workdirs have their own HEAD reflog.
j.
^ permalink raw reply
* Re: 66 patches and counting
From: Jonathan Nieder @ 2011-10-05 21:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Elijah Newren
In-Reply-To: <4E8CCC55.9070408@alum.mit.edu>
(+cc: Elijah, who has more experience in this subject than I do)
Hi,
Michael Haggerty wrote:
> My renovation of refs.c [1] is currently at 66 patches and counting.
> What can I say?: (1) I like to make changes in the smallest irreducible
> steps and (2) there is a lot that needed to be done in refs.c.
>
> When I'm done
We've seen series with fifty-something patches on this list before.
My (generic) advice:
1. Send in installments, early and often. It would not be fun if the
first ten patches have a fatal flaw that means the later ones have
to be reworked.
2. Make sure the cover letter makes people want to read the later
patches. Make sure each patch has a commit message that motivates
it alone or explains how it fits into the larger picture.
3. When a patch is not intended to cause any functional change, say
so, so reviewers can check that.
4. Include test scripts declaring what effect (or lack thereof) each
patch is supposed to have.
5. "Smallest irreducible step" is not necessarily the appropriate
granularity when publishing. "Largest piece that a person would
want to review, apply, or revert independently" is.
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-05 21:55 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel
In-Reply-To: <CAG+J_Dyn3kk7SfNZzxjoD-hK9jBQr2igmOqJojeYNHLubtSY=w@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Pinging Jay who may have know a thing or two from the history leading to
>> 37f7a85 (Teach commit about CHERRY_PICK_HEAD, 2011-02-19).
>
> Yep, I replied to Nicolas' other message.
>
> j.
This is probably different fro Nicolas's use case, but you can easily
trigger:
$ edit foo.c
$ EDITOR=: git commit --amend ;# forget to add foo.c
$ git cherry-pick other
error: Your local changes to the following files would be overwritten by
merge:
foo.c
Please, commit your changes or stash them before you can merge.
Aborting
$ EDITOR=: git commit --amend foo.c
fatal: You are in the middle of a cherry-pick -- cannot amend.
I think the sequencer state needs to be removed when the command aborts.
This needs to be fixed before 1.7.7.1.
^ permalink raw reply
* Re: Git Bug report
From: Nguyen Thai Ngoc Duy @ 2011-10-05 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Gustafsson, Federico Lucifredi, git
In-Reply-To: <7vlisz8jur.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> So if:
>> .git/ is a directory with not enough permissions.
>> ../.git/ is a directory with enough permissions.
>>
>> git would today use ../.git. You suggest that git instead would die
>> because a .git/ exists? (I'm not saying this is wrong or right).
>
> For that matter, if you have .git/ that is a directory but is not a
> repository, and ../.git/ that is, the same situation would arise. I do not
> think we should die because .git/ is not a git repository. I do not know
> if we should even warn about it.
Probably not. On the other hand we should show user how we ignored
.git if we find no good repository in the end. So maybe it's a good
idea to queue up warnings and only print before git calls die("Not a
repository").
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jonathan Nieder @ 2011-10-05 21:57 UTC (permalink / raw)
To: Jay Soffian; +Cc: Andreas Krey, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dz=9jAFBQ5fpY=d6M5Zc-BhNFi6foKJx69v3n3Km-U0rg@mail.gmail.com>
Jay Soffian wrote:
> I don't understand this. Is it about not gc'ing commits that other
> workdirs are detached on, or something more?
>
> I like that each of my workdirs have their own HEAD reflog.
Yes, sorry for the lack of clarity. I only meant that "git gc" needs
to be aware of the HEAD reflog for other workdirs (e.g., as described
in the thread following madcoder's proposal), not that it would be a
good idea for the reflogs to actually be symlinked.
^ permalink raw reply
* What's cooking in git.git (Oct 2011, #02; Wed, 5)
From: Junio C Hamano @ 2011-10-05 22:15 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
The first batch of topics that have been cooking in 'next' have now
graduated to 'master'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo, html and man:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint, master, html and man:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
url = https://github.com/gitster/git
Until kernel.org comes back to life, it might be a good idea to
tentatively have the following in your $HOME/.gitconfig:
[url "https://github.com/git/git"]
insteadOf = git://git.kernel.org/pub/scm/git/git.git
I am planning to kick some topics out of 'next' back to 'pu' to give them
a chance to be cleaned up. Not happened yet, but see below for ideas.
--------------------------------------------------
[New Topics]
* sp/smart-http-failure (2011-10-04) 1 commit
(merged to 'next' on 2011-10-05 at 73af367)
+ remote-curl: Fix warning after HTTP failure
Will merge to "master" in the second wave.
--------------------------------------------------
[Graduated to "master"]
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
Will merge to "master" in the first wave.
* bk/ancestry-path (2011-09-15) 4 commits
(merged to 'next' on 2011-09-15 at aa64d04)
+ t6019: avoid refname collision on case-insensitive systems
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
(this branch is used by jc/request-pull-show-head-4.)
Will merge to "master" in the first wave.
* cb/send-email-help (2011-09-12) 1 commit
(merged to 'next' on 2011-09-14 at ae71999)
+ send-email: add option -h
Will merge to "master" in the first wave.
* cn/eradicate-working-copy (2011-09-21) 1 commit
(merged to 'next' on 2011-09-26 at 2683d36)
+ Remove 'working copy' from the documentation and C code
Will merge to "master" in the first wave.
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
Will merge to "master" in the first wave.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
Will merge to "master" in the first wave.
* fk/use-kwset-pickaxe-grep-f (2011-09-11) 2 commits
(merged to 'next' on 2011-09-14 at 436d858)
+ obstack.c: Fix some sparse warnings
+ sparse: Fix an "Using plain integer as NULL pointer" warning
Will merge to "master" in the first wave.
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
Will merge to "master" in the first wave.
* hl/iso8601-more-zone-formats (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 270f5c7)
+ date.c: Support iso8601 timezone formats
Will merge to "master" in the first wave.
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
Will merge to "master" in the first wave.
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
(merged to 'next' on 2011-09-12 at a031347)
+ test: fetch/receive with fsckobjects
+ transfer.fsckobjects: unify fetch/receive.fsckobjects
+ fetch.fsckobjects: verify downloaded objects
We had an option to verify the sent objects before accepting a push but
lacked the corresponding option when fetching. In the light of the recent
k.org incident, a change like this would be a good addition.
Will merge to "master" in the first wave.
* jc/fetch-verify (2011-09-01) 3 commits
(merged to 'next' on 2011-09-12 at 3f491ab)
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/receive-verify.)
During a fetch, we verify that the pack stream is self consistent,
but did not verify that the refs that are updated are consistent with
objects contained in the packstream, and this adds such a check.
Will merge to "master" in the first wave.
* jc/ls-remote-short-help (2011-09-16) 1 commit
(merged to 'next' on 2011-09-26 at e24a27a)
+ ls-remote: a lone "-h" is asking for help
Will merge to "master" in the first wave.
* jc/maint-bundle-too-quiet (2011-09-19) 1 commit
(merged to 'next' on 2011-09-26 at ba140d4)
+ Teach progress eye-candy to fetch_refs_from_bundle()
Will merge to "master" in the first wave.
* jc/maint-fsck-fwrite-size-check (2011-09-11) 1 commit
(merged to 'next' on 2011-09-16 at 2258f11)
+ fsck: do not abort upon finding an empty blob
Will merge to "master" in the first wave.
* jc/receive-verify (2011-09-09) 6 commits
(merged to 'next' on 2011-09-12 at 856de78)
+ receive-pack: check connectivity before concluding "git push"
+ check_everything_connected(): libify
+ check_everything_connected(): refactor to use an iterator
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/fetch-verify.)
While accepting a push, we verify that the pack stream is self consistent,
but did not verify that the refs the push updates are consistent with
objects contained in the packstream, and this adds such a check.
Will merge to "master" in the third wave.
* jc/run-receive-hook-cleanup (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 68dd431)
+ refactor run_receive_hook()
(this branch is used by jc/signed-push and jc/signed-push-3.)
Just to make it easier to run a hook that reads from its standard input.
Will merge to "master" in the first wave.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
Will merge to "master" in the first wave.
* jc/want-commit (2011-09-15) 1 commit
(merged to 'next' on 2011-09-26 at 5841512)
+ Allow git merge ":/<pattern>"
Will merge to "master" in the first wave.
* jk/argv-array (2011-09-14) 7 commits
(merged to 'next' on 2011-09-16 at 90feab4)
+ run_hook: use argv_array API
+ checkout: use argv_array API
+ bisect: use argv_array API
+ quote: provide sq_dequote_to_argv_array
+ refactor argv_array into generic code
+ quote.h: fix bogus comment
+ add sha1_array API docs
(this branch uses jk/maint-fetch-submodule-check-fix.)
This has a slight interaction with the "pending_sha1 without having to
read the object" work on rs/pending, but otherwise OK.
Will merge to "master" in the first wave.
* jk/filter-branch-require-clean-work-tree (2011-09-15) 1 commit
(merged to 'next' on 2011-09-26 at 206a74a)
+ filter-branch: use require_clean_work_tree
Will merge to "master" in the first wave.
* jk/for-each-ref (2011-09-08) 5 commits
(merged to 'next' on 2011-09-14 at 36ed515)
+ for-each-ref: add split message parts to %(contents:*).
+ for-each-ref: handle multiline subjects like --pretty
+ for-each-ref: refactor subject and body placeholder parsing
+ t6300: add more body-parsing tests
+ t7004: factor out gpg setup
Will merge to "master" in the first wave.
* jk/maint-fetch-submodule-check-fix (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 3c73b8c)
+ fetch: avoid quadratic loop checking for updated submodules
(this branch is used by jk/argv-array.)
Will merge to "master" in the first wave.
* jn/gitweb-highlite-sanitise (2011-09-16) 1 commit
(merged to 'next' on 2011-09-26 at c79390a)
+ gitweb: Strip non-printable characters from syntax highlighter output
Will merge to "master" in the first wave.
* js/check-attr-cached (2011-09-22) 2 commits
(merged to 'next' on 2011-09-27 at 74d7b66)
+ t0003: remove extra whitespaces
+ Teach '--cached' option to check-attr
Will merge to "master" in the first wave.
* mg/branch-list (2011-09-13) 7 commits
(merged to 'next' on 2011-09-14 at 6610a2e)
+ t3200: clean up checks for file existence
(merged to 'next' on 2011-09-11 at 20a9cdb)
+ branch: -v does not automatically imply --list
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
Will merge to "master" in the first wave.
* mg/maint-doc-sparse-checkout (2011-09-21) 3 commits
(merged to 'next' on 2011-09-21 at f316dec)
+ git-read-tree.txt: correct sparse-checkout and skip-worktree description
+ git-read-tree.txt: language and typography fixes
+ unpack-trees: print "Aborting" to stderr
Will merge to "master" in the first wave.
* mm/mediawiki-as-a-remote (2011-09-28) 6 commits
(merged to 'next' on 2011-09-28 at a1c9ae5)
+ git-remote-mediawiki: allow a domain to be set for authentication
(merged to 'next' on 2011-09-27 at 7ce8254)
+ git-remote-mediawiki: obey advice.pushNonFastForward
+ git-remote-mediawiki: set 'basetimestamp' to let the wiki handle conflicts
+ git-remote-mediawiki: trivial fixes
(merged to 'next' on 2011-09-12 at 163c6a5)
+ git-remote-mediawiki: allow push to set MediaWiki metadata
+ Add a remote helper to interact with mediawiki (fetch & push)
Will merge to "master" in the first wave.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
Will merge to "master" in the first wave.
* ms/patch-id-with-overlong-line (2011-09-22) 1 commit
(merged to 'next' on 2011-09-26 at a33d0b2)
+ patch-id.c: use strbuf instead of a fixed buffer
Will merge to "master" in the first wave.
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
Will merge to "master" in the first wave.
* rj/maint-t9159-svn-rev-notation (2011-09-21) 1 commit
(merged to 'next' on 2011-09-26 at 525a567)
+ t9159-*.sh: skip for mergeinfo test for svn <= 1.4
Will merge to "master" in the first wave.
* rj/quietly-create-dep-dir (2011-09-11) 1 commit
(merged to 'next' on 2011-09-12 at 93d1c6b)
+ Makefile: Make dependency directory creation less noisy
Will merge to "master" in the first wave.
* rr/revert-cherry-pick-continue (2011-09-11) 19 commits
(merged to 'next' on 2011-09-11 at 7d78054)
+ builtin/revert.c: make commit_list_append() static
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will merge to "master" in the first wave.
Note that generalized sequencer still needs a bit more thought (see the
summary by Ram at $gmane/179613).
* sn/doc-update-index-assume-unchanged (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at 325e796)
+ Documentation/git-update-index: refer to 'ls-files'
Will merge to "master" in the first wave.
* tr/doc-note-rewrite (2011-09-13) 1 commit
(merged to 'next' on 2011-09-16 at 5fe813a)
+ Documentation: basic configuration of notes.rewriteRef
Will merge to "master" in the first wave.
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
Will merge to "master" in the first wave.
* wh/normalize-alt-odb-path (2011-09-07) 1 commit
(merged to 'next' on 2011-09-14 at 96f722b)
+ sha1_file: normalize alt_odb path before comparing and storing
Will merge to "master" in the first wave.
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
The second from the bottom one needs to be replaced with a properly
written commit log message.
Will kick back to 'pu'.
* jc/signed-push (2011-09-12) 7 commits
- push -s: support pre-receive-signature hook
- push -s: receiving end
- push -s: send signed push certificate
- push -s: skeleton
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch is tangled with jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-09-12) 4 commits
. push -s: signed push
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch is tangled with jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
I expect that both of these topics will be discarded.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Will discard.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
Will discard.
* jk/generation-numbers (2011-09-11) 8 commits
- metadata-cache.c: make two functions static
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in.
Will discard.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) in bk/ancestry-path would help.
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Incomplete with respect to backslash processing in prefix_filename(), and
also loses the ability to escape glob specials.
Will discard.
--------------------------------------------------
[Cooking]
* cb/do-not-pretend-to-hijack-long-help (2011-10-05) 1 commit
- use -h for synopsis and --help for manpage consistently
Will merge to "next".
* cp/git-web-browse-browsers (2011-10-03) 1 commit
- git-web--browse: avoid the use of eval
Will merge to "next".
* il/archive-err-signal (2011-10-05) 1 commit
- Support ERR in remote archive like in fetch/push
Will merge to "next".
* nd/daemon-log-sock-errors (2011-10-03) 1 commit
- daemon: log errors if we could not use some sockets
Will merge to "next".
* nd/document-err-packet (2011-10-03) 1 commit
(merged to 'next' on 2011-10-05 at aca0326)
+ pack-protocol: document "ERR" line
Will merge to "master" in the second wave.
* nd/git-daemon-error-msgs (2011-10-03) 1 commit
- daemon: return "access denied" if a service is not allowed
Will merge to "next".
* jc/is-url-simplify (2011-10-03) 1 commit
- url.c: simplify is_url()
Will merge to "next".
* jn/ident-from-etc-mailname (2011-10-03) 1 commit
- ident: check /etc/mailname if email is unknown
Will merge to "next".
The warning might have to be squelched further, but that can be done as a
separate patch in-tree.
* jn/no-g-plus-s-on-bsd (2011-10-03) 1 commit
- Makefile: do not set setgid bit on directories on GNU/kFreeBSD
Will merge to "next".
* js/log-show-children (2011-10-04) 1 commit
- log --children
Will merge to "next".
* rs/name-rev-usage (2011-10-03) 1 commit
(merged to 'next' on 2011-10-05 at 16d0eac)
+ name-rev: split usage string
Will merge to "master" in the second wave.
* rs/test-ctype (2011-10-03) 2 commits
(merged to 'next' on 2011-10-05 at 9a9b0e6)
+ test-ctype: add test for is_pathspec_magic
+ test-ctype: macrofy
Will merge to "master" in the second wave.
* rs/pending (2011-10-03) 8 commits
- commit: factor out clear_commit_marks_for_object_array
- checkout: use leak_pending flag
- bundle: use leak_pending flag
- bisect: use leak_pending flag
- revision: add leak_pending flag
- checkout: use add_pending_{object,sha1} in orphan check
- revision: factor out add_pending_sha1
- checkout: check for "Previous HEAD" notice in t2020
Will merge to "next" after reading the series over once more.
* ph/transport-with-gitfile (2011-10-04) 4 commits
- Add test showing git-fetch groks gitfiles
- Teach transport about the gitfile mechanism
- Learn to handle gitfiles in enter_repo
- enter_repo: do not modify input
Will merge to "next" after reading the series over once more.
* jc/grep-untracked-exclude (2011-10-04) 1 commit
- Merge branch 'jc/maint-grep-untracked-exclude' into jc/grep-untracked-exclude
(this branch uses bw/grep-no-index-no-exclude and jc/maint-grep-untracked-exclude.)
Will merge to "next".
* jc/maint-grep-untracked-exclude (2011-10-04) 1 commit
- grep: teach --untracked and --exclude-standard options
(this branch is used by jc/grep-untracked-exclude; uses bw/grep-no-index-no-exclude.)
Will merge to "next".
* dm/tree-walk (2011-09-28) 2 commits
(merged to 'next' on 2011-10-05 at ca20a51)
+ tree-walk: micro-optimization in tree_entry_interesting
+ tree-walk: drop unused parameter from match_dir_prefix
Will merge to "master" in the second wave.
* cs/perl-config-path-send-email (2011-09-30) 2 commits
(merged to 'next' on 2011-10-05 at 68dc976)
+ use new Git::config_path() for aliasesfile
+ Add Git::config_path()
Will merge to "master" in the second wave.
* jc/checkout-from-tree-keep-local-changes (2011-09-30) 1 commit
(merged to 'next' on 2011-10-05 at 15d10f7)
+ checkout $tree $path: do not clobber local changes in $path not in $tree
Will merge to "master" in the fourth wave.
* jc/apply-blank-at-eof-fix (2011-09-26) 1 commit
(merged to 'next' on 2011-10-05 at 99213f2)
+ apply --whitespace=error: correctly report new blank lines at end
Will merge to "master" in the third wave.
* nd/sparse-doc (2011-09-26) 1 commit
(merged to 'next' on 2011-10-05 at 0ee812e)
+ git-read-tree.txt: update sparse checkout examples
Will merge to "master" in the second wave.
* jp/get-ref-dir-unsorted (2011-09-30) 2 commits
- refs: Use binary search to lookup refs faster
- Don't sort ref_list too early
Will merge to "next".
* jc/parse-options-boolean (2011-09-28) 5 commits
- apply: use OPT_NOOP_NOARG
- revert: use OPT_NOOP_NOARG
- parseopt: add OPT_NOOP_NOARG
- archive.c: use OPT_BOOL()
- parse-options: deprecate OPT_BOOLEAN
Will merge to "next".
* mh/maint-notes-merge-pathbuf-fix (2011-09-27) 1 commit
(merged to 'next' on 2011-10-05 at a4ce316)
+ notes_merge_commit(): do not pass temporary buffer to other function
Will merge to "master" in the second wave.
* ph/push-to-delete-nothing (2011-09-30) 1 commit
- receive-pack: don't pass non-existent refs to post-{receive,update} hooks
Will merge to "next".
* ps/gitweb-js-with-lineno (2011-09-27) 1 commit
(merged to 'next' on 2011-10-05 at 7f7d5da)
+ gitweb: Fix links to lines in blobs when javascript-actions are enabled
Will merge to "master" in the second wave.
* zj/send-email-authen-sasl (2011-09-29) 1 commit
(merged to 'next' on 2011-10-05 at 127f3a5)
+ send-email: auth plain/login fix
Will merge to "master" in the second wave.
* jc/maint-diffstat-numstat-context (2011-09-22) 1 commit
(merged to 'next' on 2011-09-26 at 12539ab)
+ diff: teach --stat/--numstat to honor -U$num
"diff" is allowed to match the common lines differently depending on how
many context lines it is showing, so running --(num)stat with 0 lines of
context internally gives a result that may be surprising to some people.
Will merge to "master" in the second wave.
* nd/maint-sparse-errors (2011-09-22) 2 commits
(merged to 'next' on 2011-09-26 at cdcdec5)
+ Add explanation why we do not allow to sparse checkout to empty working tree
+ sparse checkout: show error messages when worktree shaping fails
Will merge to "master" in the third wave.
* rs/diff-cleanup-records-fix (2011-10-03) 2 commits
- diff: resurrect XDF_NEED_MINIMAL with --minimal
(merged to 'next' on 2011-09-27 at 3bd75d8)
+ Revert removal of multi-match discard heuristic in 27af01
Will merge to "next".
* di/fast-import-empty-tag-note-fix (2011-09-22) 2 commits
(merged to 'next' on 2011-10-05 at da6cacf)
+ fast-import: don't allow to note on empty branch
+ fast-import: don't allow to tag empty branch
Will merge to "master" in the fourth wave.
* bw/grep-no-index-no-exclude (2011-09-15) 2 commits
(merged to 'next' on 2011-09-26 at 776f13b)
+ grep --no-index: don't use git standard exclusions
+ grep: do not use --index in the short usage output
(this branch is used by jc/grep-untracked-exclude and jc/maint-grep-untracked-exclude.)
Will merge to "master" in the third wave.
* mh/check-ref-format-3 (2011-10-05) 23 commits
- add_ref(): verify that the refname is formatted correctly
- resolve_ref(): expand documentation
- resolve_ref(): also treat a too-long SHA1 as invalid
- resolve_ref(): emit warnings for improperly-formatted references
- resolve_ref(): verify that the input refname has the right format
- remote: avoid passing NULL to read_ref()
- remote: use xstrdup() instead of strdup()
- resolve_ref(): do not follow incorrectly-formatted symbolic refs
- resolve_ref(): extract a function get_packed_ref()
- resolve_ref(): turn buffer into a proper string as soon as possible
- resolve_ref(): only follow a symlink that contains a valid, normalized refname
- resolve_ref(): use prefixcmp()
- resolve_ref(): explicitly fail if a symlink is not readable
- Change check_refname_format() to reject unnormalized refnames
- Inline function refname_format_print()
- Make collapse_slashes() allocate memory for its result
- Do not allow ".lock" at the end of any refname component
- Refactor check_refname_format()
- Change check_ref_format() to take a flags argument
- Change bad_ref_char() to return a boolean value
- git check-ref-format: add options --allow-onelevel and --refspec-pattern
- t1402: add some more tests
- get_sha1_hex(): do not read past a NUL character
Will merge to "next".
* js/bisect-no-checkout (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at e94ad3e)
+ bisect: fix exiting when checkout failed in bisect_start()
Will merge to "master" in the third wave.
* jc/request-pull-show-head-4 (2011-10-05) 7 commits
(merged to 'next' on 2011-10-05 at 8f2b5a7)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Will merge to "master" in the fourth wave.
* jm/mergetool-pathspec (2011-09-26) 2 commits
(merged to 'next' on 2011-09-26 at f699566)
+ mergetool: no longer need to save standard input
+ mergetool: Use args as pathspec to unmerged files
Will merge to "master" in the second wave.
* nd/maint-autofix-tag-in-head (2011-09-18) 4 commits
(merged to 'next' on 2011-09-27 at dc8e2e3)
+ Accept tags in HEAD or MERGE_HEAD
+ merge: remove global variable head[]
+ merge: use return value of resolve_ref() to determine if HEAD is invalid
+ merge: keep stash[] a local variable
Will merge to "master" in the third wave.
* bc/attr-ignore-case (2011-09-14) 5 commits
(merged to 'next' on 2011-09-26 at 1e0814c)
+ attr: read core.attributesfile from git_default_core_config
+ attr.c: respect core.ignorecase when matching attribute patterns
+ builtin/mv.c: plug miniscule memory leak
+ cleanup: use internal memory allocation wrapper functions everywhere
+ attr.c: avoid inappropriate access to strbuf "buf" member
Will merge to "master" in the second wave.
* js/cred-macos-x-keychain-2 (2011-09-14) 1 commit
(merged to 'next' on 2011-09-26 at 4f289a4)
+ contrib: add a pair of credential helpers for Mac OS X's keychain
(this branch uses jk/http-auth-keyring.)
Will kick back to 'pu' together with 'jk/http-auth-keyring'.
* jk/default-attr (2011-09-12) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Will discard, expecting a fresh re-roll.
* jc/make-static (2011-09-14) 4 commits
(merged to 'next' on 2011-09-14 at c5943ff)
+ exec_cmd.c: prepare_git_cmd() is sometimes used
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
Will discard (or at least kick it back to 'pu').
* mz/remote-rename (2011-09-11) 4 commits
(merged to 'next' on 2011-09-26 at 5e64f68)
+ remote: only update remote-tracking branch if updating refspec
+ remote rename: warn when refspec was not updated
+ remote: "rename o foo" should not rename ref "origin/bar"
+ remote: write correct fetch spec when renaming remote 'remote'
Will merge to "master" in the second wave.
* cb/common-prefix-unification (2011-09-12) 3 commits
(merged to 'next' on 2011-09-14 at 24f571f)
+ rename pathspec_prefix() to common_prefix() and move to dir.[ch]
+ consolidate pathspec_prefix and common_prefix
+ remove prefix argument from pathspec_prefix
Will merge to "master" in the second wave.
* jn/maint-http-error-message (2011-09-06) 2 commits
(merged to 'next' on 2011-09-12 at a843f03)
+ http: avoid empty error messages for some curl errors
+ http: remove extra newline in error message
Will merge to "master" in the second wave.
* fg/submodule-auto-push (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 3fc86f7)
+ submodule.c: make two functions static
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
Will kick back to "pu" at least tentatively.
* mh/iterate-refs (2011-09-11) 7 commits
(merged to 'next' on 2011-09-27 at c289699)
+ refs.c: make create_cached_refs() static
+ Retain caches of submodule refs
+ Store the submodule name in struct cached_refs
+ Allocate cached_refs objects dynamically
+ Change the signature of read_packed_refs()
+ Access reference caches only through new function get_cached_refs()
+ Extract a function clear_cached_refs()
Will merge to "master" in the second wave.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Will merge to "master" in the second wave.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Will kick back to 'pu'.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
Will merge to "master" in the second wave.
* jk/http-auth-keyring (2011-09-28) 22 commits
(merged to 'next' on 2011-09-28 at 65ce6c2)
+ credential-cache: don't cache items without context
(merged to 'next' on 2011-09-16 at b4195eb)
+ check_expirations: don't copy over same element
+ t0300: add missing EOF terminator for <<
(merged to 'next' on 2011-09-14 at 589c7c9)
+ credential-store: use a better storage format
+ t0300: make alternate username tests more robust
+ t0300: make askpass tests a little more robust
+ credential-cache: fix expiration calculation corner cases
+ docs: minor tweaks to credentials API
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with js/cred-macos-x-keychain-2.)
Will kick back to 'pu'.
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Jay Soffian @ 2011-10-05 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, nicolas.dichtel
In-Reply-To: <7vpqib5ciw.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 5:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think the sequencer state needs to be removed when the command aborts.
Or written later in do_pick_commit().
> This needs to be fixed before 1.7.7.1.
Something like this?
diff --git i/builtin/revert.c w/builtin/revert.c
index 3117776c2c..f7fcc88871 100644
--- i/builtin/revert.c
+++ w/builtin/revert.c
@@ -384,6 +384,7 @@ static int do_pick_commit(void)
char *defmsg = NULL;
struct strbuf msgbuf = STRBUF_INIT;
int res;
+ int record_cherry_pick_head = 0;
if (no_commit) {
/*
@@ -477,7 +478,7 @@ static int do_pick_commit(void)
strbuf_addstr(&msgbuf, ")\n");
}
if (!no_commit)
- write_cherry_pick_head();
+ record_cherry_pick_head = 1;
}
if (!strategy || !strcmp(strategy, "recursive") || action == REVERT) {
@@ -514,6 +515,9 @@ static int do_pick_commit(void)
free_message(&msg);
free(defmsg);
+ if (record_cherry_pick_head)
+ write_cherry_pick_head();
+
return res;
}
^ permalink raw reply related
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-05 22:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git, nicolas.dichtel
In-Reply-To: <CAG+J_Dysix9fOCuvm5+aU7-AC4wmsxH4-MOX+yhaHEqzeN1cPg@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 5:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I think the sequencer state needs to be removed when the command aborts.
>
> Or written later in do_pick_commit().
>
>> This needs to be fixed before 1.7.7.1.
>
> Something like this?
Does it also refrain from creating sequencer state directory?
> diff --git i/builtin/revert.c w/builtin/revert.c
> index 3117776c2c..f7fcc88871 100644
> --- i/builtin/revert.c
> +++ w/builtin/revert.c
> @@ -384,6 +384,7 @@ static int do_pick_commit(void)
> char *defmsg = NULL;
> struct strbuf msgbuf = STRBUF_INIT;
> int res;
> + int record_cherry_pick_head = 0;
>
> if (no_commit) {
> /*
> @@ -477,7 +478,7 @@ static int do_pick_commit(void)
> strbuf_addstr(&msgbuf, ")\n");
> }
> if (!no_commit)
> - write_cherry_pick_head();
> + record_cherry_pick_head = 1;
> }
>
> if (!strategy || !strcmp(strategy, "recursive") || action == REVERT) {
> @@ -514,6 +515,9 @@ static int do_pick_commit(void)
> free_message(&msg);
> free(defmsg);
>
> + if (record_cherry_pick_head)
> + write_cherry_pick_head();
> +
> return res;
> }
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Nguyen Thai Ngoc Duy @ 2011-10-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vpqib8jzk.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 3:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> On Wed, Oct 5, 2011 at 12:02 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>> Could you please consider a more generic approach? What I have in mind
>>> is a mechanism to "lock" a branch, so that only commands that have the
>>> key can update it.
>>>
>>> So instead of branch.<name>.checkout, I would have something like
>>> branch.<name>.locked = <key>, where <key> is just a string. Only
>>> commands that provide the matching <key> are allowed to update the
>>> branch. In checkout case, <key> could be "checkout: worktree".
>>
>> In this case, each workdir needs its own key, so I'd have to record
>> the key somewhere, unless you meant using a key of "checkout:
>> </path/to/workdir>".
>
> That actually is how I read his message.
That's what I meant.
> I think "switch_branches()" that updates HEAD to point at a local branch
> is one good place to lock the branch, but I do not know if it is a good
> idea to hook the check into the codepaths for deletion of the branch using
> "branch -[dD]" and check-out of the branch using "checkout $branch". I
> wonder if it makes sense to add the "checking" hook into much lower level
> in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
> catch attempts to update "your" current branch by other people.
I'd aim at low-level ref manipulation because too me it affects more
than just "git checkout".
> For that
> matter, instead of switch_branches(), would it make more sense to add this
> lock/unlock logic to symbolic_ref() that repoints HEAD to other branch?
Couldn't find symbolic_ref() in current code. If you meant
create_symref(), yes that would make sense.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Nguyen Thai Ngoc Duy @ 2011-10-05 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 5:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I do not necessarily think that it is a good approach to forbid the same
> branch to be checked out in two different places, by the way. One reason
> people would want to keep multiple workdirs is so that while they are
> still working on a branch and are not yet at a good "stop point" to even
> make a temporary commit to get interrupted, they find it sometimes
> necessary to be able to build the tip of that same branch and even make a
> small in-working-tree fixes (which later will be carried back to the
> primary branch). The problem arises only when one of the repositories try
> to update or delete the branch while it is checked out in another working
> tree.
I think of two options:
- detach from the already locked branch (pretty much like what we do
with tags now)
- refuse normally but let "checkout -f" do it anyway. However the
checkout lock will remain at the original worktree. If you want to
update branch from the second checkout, do "commit -f" and take
responsibility for your action.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 22:56 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8BHeZZqsOP_+OSPfrPdkYgKQe3LgaGfo3bERD+hWT7U0g@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Thu, Oct 6, 2011 at 5:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I do not necessarily think that it is a good approach to forbid the same
>> branch to be checked out in two different places, by the way. One reason
>> people would want to keep multiple workdirs is so that while they are
>> still working on a branch and are not yet at a good "stop point" to even
>> make a temporary commit to get interrupted, they find it sometimes
>> necessary to be able to build the tip of that same branch and even make a
>> small in-working-tree fixes (which later will be carried back to the
>> primary branch). The problem arises only when one of the repositories try
>> to update or delete the branch while it is checked out in another working
>> tree.
>
> I think of two options:
>
> - detach from the already locked branch (pretty much like what we do
> with tags now)
>
> - refuse normally but let "checkout -f" do it anyway. However the
> checkout lock will remain at the original worktree. If you want to
> update branch from the second checkout, do "commit -f" and take
> responsibility for your action.
Sorry, what problem are you trying to solve? Does that "checkout -f" meant
to nuke the local changes that are not yet at a good "stop point"?
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-05 23:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel
In-Reply-To: <CAG+J_Dysix9fOCuvm5+aU7-AC4wmsxH4-MOX+yhaHEqzeN1cPg@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 5:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I think the sequencer state needs to be removed when the command aborts.
>
> Or written later in do_pick_commit().
As a general direction, I think it makes tons of sense ot delay writing
out these state files before you really commit that the user will be in
the cherry-pick (or revert) sequence.
I am not sure if do_pick_commit() is the best place to do so. Wouldn't it
be necessary to special case the first round at least? The pick can fail
in one of two ways:
- It does not even start. This is the case I illustrated in the earlier
message, and we do not want to leave sequencer state.
- It stops with conflict. At this point, it probably is OK to say that
the user is committed to go with the sequencer flow and the next step
would be to help Git resolve conflicts and proceed, and in this case we
do want the sequencer state.
And once we picked/reverted at least one commit, if there are more, the
user knows the sequencer flow is in progress, and it is perfectly fine to
see the error message from "commit --amend".
It's just the "commit --amend" message that says I cannot amend felt
utterly out of place, immediately after seeing "cherry-pick" that tried to
pick only one commit did _not_ even start.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Nguyen Thai Ngoc Duy @ 2011-10-05 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9f59p5.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Thu, Oct 6, 2011 at 5:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> I do not necessarily think that it is a good approach to forbid the same
>>> branch to be checked out in two different places, by the way. One reason
>>> people would want to keep multiple workdirs is so that while they are
>>> still working on a branch and are not yet at a good "stop point" to even
>>> make a temporary commit to get interrupted, they find it sometimes
>>> necessary to be able to build the tip of that same branch and even make a
>>> small in-working-tree fixes (which later will be carried back to the
>>> primary branch). The problem arises only when one of the repositories try
>>> to update or delete the branch while it is checked out in another working
>>> tree.
>>
>> I think of two options:
>>
>> - detach from the already locked branch (pretty much like what we do
>> with tags now)
>>
>> - refuse normally but let "checkout -f" do it anyway. However the
>> checkout lock will remain at the original worktree. If you want to
>> update branch from the second checkout, do "commit -f" and take
>> responsibility for your action.
>
> Sorry, what problem are you trying to solve? Does that "checkout -f" meant
> to nuke the local changes that are not yet at a good "stop point"?
I meant "git checkout" on the already locked branch is refused, but
"git checkout -f" in that case will act just like "git checkout"
ignoring all locks. But I forgot that "git checkout -f" also discards
worktree changes. Maybe "git checkout --ignore-locks" instead of "git
checkout -f".
--
Duy
^ 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