* [PATCH 1/2] Add top-level maintainers file with email/canonical repository information
From: Jason Holden @ 2012-12-30 18:18 UTC (permalink / raw)
To: git; +Cc: gitster, paulus, patthoyts, Jason Holden
In-Reply-To: <1356891535-5647-1-git-send-email-jason.k.holden.swdev@gmail.com>
Certain parts of git have a semi-formalized workflow for
incoming patches. This file documents the maintainers, their area of
specialization, their email address, and their canonical repository against
which patches should be submitted.
Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
MAINTAINERS | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000..ed23b21
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,17 @@
+Core Git/Overall Maintainer:
+ Junio C Hamano <gitster@pobox.com>
+ git://git.kernel.org/pub/scm/git/git.git
+
+
+The GUI's packaged with git (git-gui and gitk) are maintained
+upstream of the core git repository. Their contact information
+and canonical repositories are below. Patches to improve these utilities
+should be made against the tree's referenced below
+
+gitk:
+ Paul Mackerras <paulus@samba.org>
+ git://ozlabs.org/~paulus/gitk
+
+git-gui:
+ Pat Thoyts <patthoyts@users.sourceforge.net>
+ git://repo.or.cz/git-gui
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply related
* [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Jason Holden @ 2012-12-30 18:18 UTC (permalink / raw)
To: git; +Cc: gitster, paulus, patthoyts, Jason Holden
I spent a good amount of time yesterday figuring out the correct workflow
to submit a change to gitk. As I understand it, gitk (and I think git-gui)
are maintained upstream of git, and patches should be sent to the git email
list against the upstream repo. I think a top-level MAINTAINERS file would
help new contributers like me get orientated, especially in the cases of these
upstream projects that require a somewhat non-standard workflow
I also added some additional clarifications to SubmittingPatches that
clarifies the additional steps required to submit patches against the guis.
Please double check that I've got the correct email addresses and canonical
repositories
I'm guessing there are additional Maintainers who should be added to the
MAINTAINERS file, I just haven't followed to email list closely enough to
know all the formal/informal workflows that should be observed.
Jason Holden (2):
Add top-level maintainers file with email/canonical repository
information
Provide better guidance for submitting patches against git-gui, gitk
Documentation/SubmittingPatches | 11 +++++++++++
MAINTAINERS | 17 +++++++++++++++++
2 files changed, 28 insertions(+)
create mode 100644 MAINTAINERS
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply
* Heads up, an emergency fix for git-cvsimport is coming shortly
From: Eric S. Raymond @ 2012-12-30 19:21 UTC (permalink / raw)
To: git
Bad news: the combination of cvsps and the existing git-cvsimport
script is seriously broken in both places. This morning I fixed a
nasty bug in cvsps's branch detection and shipped 3.3. This is a
different bug from the broken (and now removed) ancestry-branch
tracking.
Good news: I have fixed all the urgent bugs (and now you know how I
spent my holidays). Somewhat to my surprise, half the problems listed
on the git-cvsimport manual page turned out to be problems in
git-cvsimport itself, not more cvsps lossage. Those bugs are dead.
cvsps is now much better about warning when it cannot translate a tag
or sees a dubious branch structure. I've also enhanced git-cvsimport
to have an engine switch so it can optionally use cvs2git as its
conversion engine. If and when I can get parsecvs back into working
shape, I will add it to the set of supported engines.
I have a test suite that proves fixes for all the urgent problems, but
that needs a bit more work before I'm willing to call it done.
In a few days I will ship a patch that replaces git-cvsimport with a
working version and removes the t960[123] tests from the git tree.
Those are not actually tests of git-cvsimport itself but of the
underlying conversion engine, and now form about half of cvsps's own
regression-test suite.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
It is proper to take alarm at the first experiment on our
liberties. We hold this prudent jealousy to be the first duty of
citizens and one of the noblest characteristics of the late
Revolution. The freemen of America did not wait till usurped power had
strengthened itself by exercise and entangled the question in
precedents. They saw all the consequences in the principle, and they
avoided the consequences by denying the principle. We revere this
lesson too much ... to forget it -- James Madison.
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Junio C Hamano @ 2012-12-30 20:26 UTC (permalink / raw)
To: Jason Holden; +Cc: git, paulus, patthoyts
In-Reply-To: <1356891535-5647-1-git-send-email-jason.k.holden.swdev@gmail.com>
Jason Holden <jason.k.holden.swdev@gmail.com> writes:
> I spent a good amount of time yesterday figuring out the correct workflow
> to submit a change to gitk.
Thanks; I just realized that nothing in Documentation/ hierarchy
mentions these; they are only mentioned in "A Note from the
Maintainer" I send out every once in a while (kept in MaintNotes of
'todo' branch):
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
Perhaps the update should mention po/ as well?
^ permalink raw reply
* Re: [RFC] pack-objects: compression level for non-blobs
From: Jeff King @ 2012-12-30 21:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: David Michael Barr, Git Mailing List
In-Reply-To: <CACsJy8C4UttGKcw11do1POcHZJM7iZ2r7F3ESOqEnWL8kdz+dQ@mail.gmail.com>
On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
> > $ cd objects/pack && ls
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.commits
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.idx
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.pack
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.parents
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.timestamps
> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.trees
> >
> > Each file describes the objects in the matching pack. If a new pack is
> > generated, you'd throw away the old cache files along with the old pack,
> > and generate new ones. Or not. These are totally optional, and an older
> > version of git will just ignore them. A newer version will use them if
> > they're available, and otherwise fallback to the existing code (i.e.,
> > reading the whole object from the pack). So you can generate them at
>
> You have probably thought about this (and I don't have the source to
> check first), but we may need to version these extra files so we can
> change the format later if needed. Git versions that do not recognize
> new versions simply ignore the cahce.
Agreed. The current code has a 4-byte magic, followed by a 4-byte
version number, followed by a 4-byte record size[1]. Then the data,
followed by the pack sha1, followed by a sha1 of all of the preceding
data. So you can verify the validity of any cache file (both its
checksum, and that it matches the right packfile), just as you can with
a ".idx" file.
[1] Probably the magic and version should be per-file-type, and the
record size should be implicit from that; right now I make
assumptions about what is in the files based on their names, but
that is not part of the checksum.
> > repack time, later on, or not at all. For now I have a separate command
> > that generates them based on the pack index; if this turns out to be a
> > good idea, it would probably get called as part of "repack".
>
> I'd like to make it part of index-pack, where we have nearly
> everything in memory. But let's leave it as a separate command first.
Yeah, in the long run that may work. The steps I figured were:
1. Optional, external command. Let people experiment.
2. Once it has proven itself, run the command from index-pack by
default (or with a config option).
3. If it turns out too slow, move the generation directly into the
index-pack process.
The current iteration does not seem all that slow, but that is because I
am mostly picking static data out of the commits. So I have to load the
commits, and that's it. But something like reachability might be more
expensive (OTOH, it will always be more expensive, whether we have the
objects in memory or not).
> > Each file is a set of fixed-length records. The "commits" file contains
> > the sha1 of every commit in the pack (sorted). A binary search of the
> > mmap'd file gives the position of a particular commit within the list,
>
> I think we could avoid storing sha-1 in the cache with Shawn's idea
> [1]. But now I read it again I fail to see it :(
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/206485
Right. My implementation is very similar to what Shawn said there. I.e.,
the timestamps file is literally 4 bytes times the number of commits.
The parents file is 40 bytes per commit (2 parents, with a marker to
indicate "more or less than 2"), though a lot of it is zero bytes.
Some alternatives I'm thinking about are:
1. Using non-fixed-size records, which would allow trivial compression
of entries like null sha1s. This would mean adding a separate
lookup table, though, mapping sha1s to offsets. Still, even a
32-bit offset is only 4 bytes per commit. If it meant dropping 40
bytes of zeroes from the 2nd parent field out of half of all
commits, that would be a win space-wise. It would be a
double-indirect lookup, but it's constant effort, and only two page
hits (which would be warm after the first lookup anyway).
2. Storing offsets to objects in the packfile rather than their sha1s.
This would save a lot of space, but would mean we couldn't refer to
parents outside of the pack, but that may be OK. This is an
optimization, and the case we want to target is a fully (or mostly)
packed repo. It's OK to have the lookup fail and fallback to
accessing the object.
3. Dropping the "commits" file and just using the pack-*.idx as the
index. The problem is that it is sparse in the commit space. So
just naively storing 40 bytes per entry is going to waste a lot of
space. If we had a separate index as in (1) above, that could be
dropped to (say) 4 bytes of offset per object. But still, right now
the commits file for linux-2.6 is about 7.2M (20 bytes times ~376K
commits). There are almost 3 million total objects, so even storing
4 bytes per object is going to be worse.
4. Making a new index version that stores the sha1s separated by type.
This means we can piggy-back on the regular index to get a packed
list of just commits. But it also means that regular sha1 lookups
of the objects have to look in several places (unless the caller
annotates the call to read_sha1_object with "I am expecting this
sha1 to be a commit"). And of course it means bumping the index
version, which is a pain. The external index means it can be
completely optional on top of the current index/pack.
> Depending on the use case, we could just generate packv4-like cache
> for recently-used trees only. I'm not sure how tree cache impact a
> merge operation on a very large worktree (iow, a lot of trees
> referenced from HEAD to be inflated). This is something a cache can
> do, but a new pack version cannot.
I do not care too much about the cost of running merge on a large
working tree. Of course it's better to make our optimizations as
generally applicable as possible, but there is a lot of other work going
on in a merge. The really painful, noticeable, repetitive bits right now
are:
1. Running git-prune.
2. Creating a pack from git-upload-pack.
Which are both just reachability problems. Something like "git log --
<pathspec>" would also be helped by packv4-ish tree access patterns,
though, but not by reachability bitmaps. And that may be something
worth caring about.
> Yes. And if narrow clone ever comes, which needs --objects limited by
> pathspec, we could just produce extra bitmaps for frequently-used
> pathspecs and only allow narrow clone with those pathspecs.
I hadn't thought about that. But yeah, because of the optional, external
nature, there's no reason you couldn't have extra bitmap sets for
specialized situations.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] dir.c: Make git-status --ignored more consistent
From: Junio C Hamano @ 2012-12-30 21:36 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Jeff King, Adam Spiers
In-Reply-To: <CALWbr2w=CWkpbJhC5sjd9HnErmWj9JQnD6UUiDM91ovJ_-16vA@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> By the way, that merges without conflicts with Adam's series, but it
> will not compile as he renamed functions that I'm now using
> (path_excluded() -> is_path_excluded() that is).
>
> By the way, Junio, how do you handle this situation as a maintainer ?
> Do you keep a note to manually make the change every time you remerge
> the series together ? That is the kind of use-case you can't handle
> with git-rerere, and I've been trying to find a solution to it.
I'll finish the write-up on jc/doc-maintainer topic not in a very
distant future, but not today.
In the meantime, the hint is in the use of refs/merge-fix/ hierarchy
in the Reintegrate script found on my 'todo' branch (which I have a
separate clone/checkout of in "Meta/" directory in my main working
tree).
^ permalink raw reply
* Re: Aw: Re: [PATCH 0/3] Move CodingGuidelines and SubmittingPatches to ./Documentation/technical
From: Junio C Hamano @ 2012-12-30 21:40 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: artagnon, git
In-Reply-To: <1965427282.405137.1356879393533.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
>
> ./Documentation/technical contains not only API documentation but also
> several other documents describing Git implementation topics and thus
> is the place someone wanting to join Git development should look at.
Implementation details are part of API; CG and SP are social not
technical.
Also CG and SP are in the part of the documents that are not
installed for end-users and that is their right place. They matter
only to the people who grab our source code.
^ permalink raw reply
* Re: Heads up, an emergency fix for git-cvsimport is coming shortly
From: Chris Rorvick @ 2012-12-31 0:15 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121230192116.C2A2444143@snark.thyrsus.com>
On Sun, Dec 30, 2012 at 1:21 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Bad news: the combination of cvsps and the existing git-cvsimport
> script is seriously broken in both places. This morning I fixed a
> nasty bug in cvsps's branch detection and shipped 3.3. This is a
> different bug from the broken (and now removed) ancestry-branch
> tracking.
I tried the new version and found I'm unable to import via pserver:
$ ./cvsps --root :pserver:me@localhost:/cvsroot module
cvsps: connect error: Connection refused
cvsps: can't get CVS log data: Connection refused
Running 2.2b1 (the version packaged w/ Fedora 17) with the same
arguments with the addition of --cvs-direct connects OK. I haven't
taken much time to look into this, so I might be doing something dumb.
Thought I'd find out if this is a known issue before delving into it.
Also, I'm curious what impact removing the caching from cvsps will
have on incremental imports. Is there any?
Thanks,
Chris Rorvick
^ permalink raw reply
* Re: Heads up, an emergency fix for git-cvsimport is coming shortly
From: Eric S. Raymond @ 2012-12-31 1:23 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git
In-Reply-To: <CAEUsAPZ7kzc4qYSvD-YCk9sqQOuW219gOWyxpGqfkxmF2VC-PQ@mail.gmail.com>
Chris Rorvick <chris@rorvick.com>:
> I tried the new version and found I'm unable to import via pserver:
>
> $ ./cvsps --root :pserver:me@localhost:/cvsroot module
> cvsps: connect error: Connection refused
> cvsps: can't get CVS log data: Connection refused
>
> Running 2.2b1 (the version packaged w/ Fedora 17) with the same
> arguments with the addition of --cvs-direct connects OK. I haven't
> taken much time to look into this, so I might be doing something dumb.
> Thought I'd find out if this is a known issue before delving into it.
Your problem does reproduce here. This paragraph from the output of
'aptitude show cvs' may be relevant:
This package contains a CVS binary which can act as both client and server,
although there is no CVS dæmon; to access remote repositories, please use
:extssh: not :pserver: any more.
It's therefore possible there's something slightly busted about the pserver
method at the CVS end, and the 3.[23] code trips over it even though the old
code did not. Note that new cvsps uses cvs-direct mode all the time; the old
support for fetching logs through local CVS commands is gone.
I use
cvsps --root :local:$PWD/repo module
for my testing, and that works. I'm up to my ears in finishing up the
test suite and tracking bugs in the repo-analysis code; if you want to
speed the process up, try running a :pserver: fetch with -v on under
both old and new code to see how the protocol transactions differ.
> Also, I'm curious what impact removing the caching from cvsps will
> have on incremental imports. Is there any?
Not that I know of. The caching was a performance hack for human viewing
of changesets.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* cvsps import failure
From: Eric S. Raymond @ 2012-12-31 2:28 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git
Chris Rorvick <chris@rorvick.com>:
> I tried the new version and found I'm unable to import via pserver:
And now I know why. One of the cvsps fix patches I merged from Yann
Dirson's collection changed the --root option parsing in an
incompatible way. As soon as I figure out what it's doing I'll
either revert it or document the new behavior.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The price of liberty is, always has been, and always will be blood. The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty. Are
you free? -- Andrew Ford
^ permalink raw reply
* Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
From: Paul Mackerras @ 2012-12-31 4:27 UTC (permalink / raw)
To: Jason Holden; +Cc: git
In-Reply-To: <1356826576-24334-1-git-send-email-jason.k.holden.swdev@gmail.com>
On Sat, Dec 29, 2012 at 07:16:16PM -0500, Jason Holden wrote:
> When first doing a merge in git-gui, the "Visualize Merge" button is
> quite helpful to visualize the changes due to a merge.
> But once the merge is complete, there's not a similarly convenient
> way to recreate that merge view in gitk.
>
> This commit adds to gitk the ability to right-click on a merge commit and
> bring up a new gitk window displaying only those commits involved in
> the merge.
>
> When right-clicking on a non-merge commit, this option is grayed out. This
> patch also supports correct visualization of octopus merges
Thanks for the patch. I have a couple of comments about it. First,
the exec command waits for the process to complete, which means that
the initial gitk GUI will be unresponsive until the user quits the
gitk window showing the merge, which could be quite confusing for the
user.
Secondly, gitk already has support for showing multiple views of a
repository, that is, different subsets of the commits. Wouldn't it be
much better to have your new menu item simply create a new view
showing the merge, rather than creating a whole new window?
Paul.
^ permalink raw reply
* Aw: Re: Aw: Re: [PATCH 0/3] Move CodingGuidelines and SubmittingPatches to ./Documentation/technical
From: Thomas Ackermann @ 2012-12-31 9:33 UTC (permalink / raw)
To: gitster, th.acker; +Cc: artagnon, git
In-Reply-To: <7v1ue7fcbh.fsf@alter.siamese.dyndns.org>
>
> Implementation details are part of API; CG and SP are social not
> technical.
>
This depends on your definition of "social" ;-)
>
> Also CG and SP are in the part of the documents that are not
> installed for end-users and that is their right place. They matter
> only to the people who grab our source code.
>
But isn't that true for all files in ./technical? CG and SP currently
are in ./Documentation which contains *only* files which are installed
for end-users with CG and SP the only exception ...
---
Thomas
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Thomas Ackermann @ 2012-12-31 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <7va9svffr4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Thanks; I just realized that nothing in Documentation/ hierarchy
> mentions these; they are only mentioned in "A Note from the
> Maintainer" I send out every once in a while (kept in MaintNotes of
> 'todo' branch):
>
Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?
---
Thomas
^ permalink raw reply
* Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
From: Martin Fick @ 2012-12-31 10:30 UTC (permalink / raw)
To: Michael Haggerty, Shawn Pearce; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <201212271611.52203.mfick@codeaurora.org>
On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote:
> It concerns me that git uses any locking at all, even for
> refs since it has the potential to leave around stale
> locks.
> ...
> [a previous not so great attempt to fix this]
> ...
I may have finally figured out a working loose ref update
mechanism which I think can avoid stale locks. Unfortunately
it requires atomic directory renames and universally unique
identifiers (uuids). These may be no-go criteria? But I
figure it is worth at least exploring this idea because of the
potential benefits?
The general approach is to setup a transaction and either
commit or abort it. A transaction can be setup by renaming
an appropriately setup directory to the "ref.lock" name. If
the rename succeeds, the transaction is begun. Any actor can
abort the transaction (up until it is committed) by simply
deleting the "ref.lock" directory, so it is not at risk of
going stale. However, once the actor who sets up the
transaction commits it, deleting the "ref.lock" directory
simply aids in cleaning it up for the next transaction
(instead of aborting it).
One important piece of the transaction is the use of uuids.
The uuids provide a mechanism to tie the atomic commit pieces
to the transactions and thus to prevent long sleeping process
from inadvertently performing actions which could be out of
date when they wake finally up. In each case, the atomic
commit piece is the renaming of a file. For the create and
update pieces, a file is renamed from the "ref.lock" dir to
the "ref" file resulting in an update to the sha for the ref.
However, in the delete case, the "ref" file is instead renamed
to end up in the "ref.lock" directory resulting in a delete
of the ref. This scheme does not affect the way refs are read
today,
To prepare for a transaction, an actor first generates a uuid
(an exercise I will delay for now). Next, a tmp directory
named after the uuid is generated in the parent directory for
the ref to be updated, perhaps something like: ".lock_uuid".
In this directory is places either a file or a directory named
after the uuid, something like: ".lock_uuid/,uuid". In the
case of a create or an update, the new sha is written to this
file. In the case of a delete, it is a directory.
Once the tmp directory is setup, the initiating actor
attempts to start the transaction by renaming the tmp
directory to "ref.lock". If the rename fails, the update
fails. If the rename succeeds, the actor can then attempt to
commit the transaction (before another actor aborts it).
In the case of a create, the actor verifies that "ref" does
not currently exist, and then renames the now named
"ref.lock/uuid" file to "ref". On success, the ref was
created.
In the case of an update, the actor verifies that "ref"
currently contains the old sha, and then also renames the now
named "ref.lock/uuid" file to "ref". On success, the ref was
updated.
In the case of a delete, the actor may verify that "ref"
currently contains the sha to "prune" if it needs to, and
then renames the "ref" file to "ref.lock/uuid/delete". On
success, the ref was deleted.
Whether successful or not, the actor may now simply delete
the "ref.lock" directory, clearing the way for a new
transaction. Any other actor may delete this directory at
any time also, likely either on conflict (if they are
attempting to initiate a transaction), or after a grace
period just to cleanup the FS. Any actor may also safely
cleanup the tmp directories, preferably also after a grace
period.
One neat part about this scheme is that I believe it would be
backwards compatible with the current locking mechanism since
the transaction directory will simply appear to be a lock to
older clients. And the old lock file should continue to lock
out these newer transactions.
Due to this backwards compatibility, I believe that this
could be incrementally employed today without affecting very
much. It could be deployed in place of any updates which
only hold ref.locks to update the loose ref. So for example
I think it could replace step 4a below from Michael
Haggerty's description of today's loose ref pruning during
ref packing:
> * Pack references:
...
> 4. prune_refs(): for each ref in the ref_to_prune list,
> call prune_ref():
>
> a. Lock the reference using lock_ref_sha1(),
> verifying that the recorded SHA1 is still valid. If it
> is, unlink the loose reference file then free the lock;
> otherwise leave the loose reference file untouched.
I think it would also therefore be able to replace the loose
ref locking in Michael's new ref-packing scheme as well as
the locking in Michael's new ref deletion scheme (again steps
4):
> * Delete reference foo:
...
> 4. Delete loose ref for "foo":
>
> a. Acquire the lock $GIT_DIR/refs/heads/foo.lock
>
> b. Unlink $GIT_DIR/refs/heads/foo if it is unchanged.
> If it is changed, leave it untouched. If it is deleted,
> that is OK too.
>
> c. Release lock $GIT_DIR/refs/heads/foo.lock
...
> * Pack references:
...
> 4. prune_refs(): for each ref in the ref_to_prune list,
> call prune_ref():
>
> a. Lock the loose reference using lock_ref_sha1(),
> verifying that the recorded SHA1 is still valid
>
> b. If it is, unlink the loose reference file
> (otherwise, leave it untouched)
>
> c. Release the lock on the loose reference
To be honest, I suspect I missed something obvious because
this seems almost too simple to work. I am ashamed that it
took me so long to come up with (of course, I will be even
more ashamed :( when it is shown to be flawed!) This scheme
also feels extensible. if there are no obvious flaws in it, I
will try to post solutions for ref packing and for multiple
repository/ref transactions also soon.
I welcome any comments/criticisms,
-Martin
^ permalink raw reply
* git filter-branch doesn't dereference annotated tags
From: Grégory Pakosz @ 2012-12-31 14:36 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hello,
I noticed git-filter-branch doesn't dereference annotated tags prior
to invoking git update-ref -d.
Please find a patch attached that changes the call to git update-ref:
-git update-ref -m "filter-branch: delete" -d "$ref" $sha1
+git update-ref -m "filter-branch: delete" -d $(git rev-parse --verify
"$ref^{commit}") $sha1
Regards,
Gregory
[-- Attachment #2: 0001-git-filter-branch-Dereference-annotated-tags-upon-de.patch --]
[-- Type: application/octet-stream, Size: 869 bytes --]
From cee5462f26bbb280f471ba1220398924bfd4bfd7 Mon Sep 17 00:00:00 2001
From: Gregory Pakosz <gpakosz@visionobjects.com>
Date: Mon, 31 Dec 2012 15:30:36 +0100
Subject: [PATCH] git-filter-branch: Dereference annotated tags upon deletion
git-filter-branch didn't dereference annotated tags upon deletion which made
git-update-ref -d unhappy.
---
git-filter-branch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..773a91b 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ do
case "$rewritten" in
'')
echo "Ref '$ref' was deleted"
- git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
+ git update-ref -m "filter-branch: delete" -d $(git rev-parse --verify "$ref^{commit}") $sha1 ||
die "Could not delete $ref"
;;
$_x40)
--
1.8.0.1
^ permalink raw reply related
* git filter-branch doesn't dereference annotated tags
From: Grégory Pakosz @ 2012-12-31 16:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]
Please disregard the previous email that contains an incorrect fix
suggestion. I wish my first contribution was flawless.
Here is what's happening.
git-filter-branch let git-update-ref -d verify that the value for $ref
matches $sha1.
However, when $ref points to an annotated tag that is being deleted,
that verification fails because $sha1 is the commit underneath.
I think there are two possible fixes:
1) either make git-filter-branch dereference annotated tags and do
the verification itself then use the two arguments version of git
update-ref
2) in the case of an annotated tag, pass another <old value> to git update-ref
Please find below a patch that implements solution 1). Please note the
patch doesn't contain a unit test for this situation as I wasn't sure
how to provide one. Yet I tested it on the repository I'm working on.
Gregory
>From 9d21960088a61bfbac1ffdb4b13e3038f88ab4d6 Mon Sep 17 00:00:00 2001
From: Gregory Pakosz <gpakosz@visionobjects.com>
Date: Mon, 31 Dec 2012 15:30:36 +0100
Subject: [PATCH] git-filter-branch: support annotated tags deletion
git-filter-branch let git-update-ref -d verify that the value for $ref matches
$sha1. However, when $ref is an annotated tag being deleted that verfication
fails because $sha1 corresponds to a commit object.
Instead of asking git-update-ref to verify values actually match, dereference
$ref ourselves and test against $sha1 first. Then invoke git-update-ref with two
arguments.
Signed-off-by: Gregory Pakosz <gpakosz@visionobjects.com>
---
git-filter-branch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..bbee6d0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ do
case "$rewritten" in
'')
echo "Ref '$ref' was deleted"
- git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
+ test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git
update-ref -m "filter-branch: delete" -d "$ref" ||
die "Could not delete $ref"
;;
$_x40)
--
1.8.0.1
[-- Attachment #2: 0001-git-filter-branch-support-annotated-tags-deletion.patch --]
[-- Type: application/octet-stream, Size: 1211 bytes --]
From 9d21960088a61bfbac1ffdb4b13e3038f88ab4d6 Mon Sep 17 00:00:00 2001
From: Gregory Pakosz <gpakosz@visionobjects.com>
Date: Mon, 31 Dec 2012 15:30:36 +0100
Subject: [PATCH] git-filter-branch: support annotated tags deletion
git-filter-branch let git-update-ref -d verify that the value for $ref matches
$sha1. However, when $ref is an annotated tag being deleted that verfication
fails because $sha1 corresponds to a commit object.
Instead of asking git-update-ref to verify values actually match, dereference
$ref ourselves and test against $sha1 first. Then invoke git-update-ref with two
arguments.
Signed-off-by: Gregory Pakosz <gpakosz@visionobjects.com>
---
git-filter-branch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..bbee6d0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ do
case "$rewritten" in
'')
echo "Ref '$ref' was deleted"
- git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
+ test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git update-ref -m "filter-branch: delete" -d "$ref" ||
die "Could not delete $ref"
;;
$_x40)
--
1.8.0.1
^ permalink raw reply related
* Re: git.wiki.kernel.org spam ...
From: Johannes Schindelin @ 2012-12-31 17:08 UTC (permalink / raw)
To: rupert THURNER; +Cc: git
In-Reply-To: <CAJs9aZ_Nu9PzYYLc55Lr8E+UefohK+pSUbF5i8Lu4V_gr2KHPw@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 707 bytes --]
Hi Rupert,
On Sat, 29 Dec 2012, rupert THURNER wrote:
> ich hab gesehen, du bist ober-meister des kernle.org git wikis. da
> gibt es ganz schön viel neue user und spam derzeit, zb:
> https://git.wiki.kernel.org/index.php?title=User_talk:Bridgetevans0521&redirect=no
>
> möchtest du das erzeugen von user accounts erschweren, wie zb hier:
> http://kiwix.org/index.php/Special:UserLogin?type=signup&returnto=Main_Page/en
>
> falls du noch leute als admin haben willst, ich melde mich freiwillig,
> ThurnerRupert ist mein account.
Since my trustworthiness was questioned, I have stopped completely with
the maintenance of the Wiki.
The mailing list (Cc:ed) may have additional comments.
Ciao,
Johannes
^ permalink raw reply
* Re: [RFC] pack-objects: compression level for non-blobs
From: Shawn Pearce @ 2012-12-31 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, David Michael Barr, Git Mailing List
In-Reply-To: <20121230213124.GA15946@sigill.intra.peff.net>
This thread is pretty interesting. Unfortunately the holidays have
kept me busy. But I am excited by the work David and Peff are doing.
:-)
On Sun, Dec 30, 2012 at 1:31 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > $ cd objects/pack && ls
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.commits
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.idx
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.pack
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.parents
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.timestamps
>> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.trees
>> >
>> > Each file describes the objects in the matching pack. If a new pack is
>> > generated, you'd throw away the old cache files along with the old pack,
>> > and generate new ones. Or not. These are totally optional, and an older
>> > version of git will just ignore them. A newer version will use them if
>> > they're available, and otherwise fallback to the existing code (i.e.,
>> > reading the whole object from the pack). So you can generate them at
>>
>> You have probably thought about this (and I don't have the source to
>> check first), but we may need to version these extra files so we can
>> change the format later if needed. Git versions that do not recognize
>> new versions simply ignore the cahce.
>
> Agreed. The current code has a 4-byte magic, followed by a 4-byte
> version number, followed by a 4-byte record size[1]. Then the data,
> followed by the pack sha1, followed by a sha1 of all of the preceding
> data. So you can verify the validity of any cache file (both its
> checksum, and that it matches the right packfile), just as you can with
> a ".idx" file.
Put the pack sha1 into the header, rather than the trailer. Its really
annoying that you read the header, determine you probably understand
this file, and then have to seek to END-40 to read the pack sha1 and
verify it matches the pack. In an ideal world the pack sha1 would have
been the file name, making this less of an issue, but someone didn't
anticipate repacking the same object set with possibly different
results. :-(
The idx format is kind of wrong here, I wish we had put the pack sha1
into the header. Given that we mmap the files the 20 bytes in front
vs. 20 bytes in the trailer wouldn't have made any difference on
access cost.
>> > Each file is a set of fixed-length records. The "commits" file contains
>> > the sha1 of every commit in the pack (sorted). A binary search of the
>> > mmap'd file gives the position of a particular commit within the list,
>>
>> I think we could avoid storing sha-1 in the cache with Shawn's idea
>> [1]. But now I read it again I fail to see it :(
>>
>> [1] http://article.gmane.org/gmane.comp.version-control.git/206485
>
> Right. My implementation is very similar to what Shawn said there. I.e.,
> the timestamps file is literally 4 bytes times the number of commits.
> The parents file is 40 bytes per commit (2 parents, with a marker to
> indicate "more or less than 2"), though a lot of it is zero bytes.
Hmm, after re-reading [1] I still like my idea better. But I won't
find the time to code it myself, so I'll have to go with whatever
someone else writes. :-)
Since tree pointers are also required when parsing a commit (even if
they might not get used e.g. `git log master`) maybe this should be 16
bytes per commit storing the commit time, tree pointer, and 2 parents,
with the last 3 fields using the N-th object in the sorted sha1 list
in the idx. Sorting the file by pack stream ordering gives you good
locality during rev-list operations and makes it compact if
pack-objects adheres to writing commits before other objects.
Unfortunately this ordering requires the pack reverse index in memory
to translate from sha1 to position in the cache file. Making the
reverse index is a non-trivial cost that may dominate the running time
for smaller traversals, or the startup time for `git log` outputting
to the pager.
> Some alternatives I'm thinking about are:
>
> 1. Using non-fixed-size records, which would allow trivial compression
> of entries like null sha1s. This would mean adding a separate
> lookup table, though, mapping sha1s to offsets. Still, even a
> 32-bit offset is only 4 bytes per commit. If it meant dropping 40
> bytes of zeroes from the 2nd parent field out of half of all
> commits, that would be a win space-wise. It would be a
> double-indirect lookup, but it's constant effort, and only two page
> hits (which would be warm after the first lookup anyway).
Or use a 16 byte fixed width record (see above).
> 2. Storing offsets to objects in the packfile rather than their sha1s.
> This would save a lot of space, but would mean we couldn't refer to
> parents outside of the pack, but that may be OK. This is an
> optimization, and the case we want to target is a fully (or mostly)
> packed repo. It's OK to have the lookup fail and fallback to
> accessing the object.
I glossed over this in both [1] and this message. I think its
perfectly reasonable to require parsing the commit when the commit's
parents are outside of the pack. These edge commits are infrequent
compared to the number of commits within the pack. Just mark them the
same way you mark an octopus merge, so the reader knows the parent
data is not available in the cache. For most repositories the bulk of
the commits will be in a single giant pack that contains history to
the root.
I wouldn't store the byte offsets here, those are possibly 8 bytes
wide on bigger packs. Instead store the Nth position in the pack
stream. Even if you store byte offsets you need to use the pack
reverse index to recover the SHA-1 in log N time. If you store the Nth
position you also use the pack reverse index, but you can fit all
objects from that pack in 4 bytes rather than 8 bytes per reference.
> 3. Dropping the "commits" file and just using the pack-*.idx as the
> index. The problem is that it is sparse in the commit space. So
> just naively storing 40 bytes per entry is going to waste a lot of
> space. If we had a separate index as in (1) above, that could be
> dropped to (say) 4 bytes of offset per object. But still, right now
> the commits file for linux-2.6 is about 7.2M (20 bytes times ~376K
> commits). There are almost 3 million total objects, so even storing
> 4 bytes per object is going to be worse.
Fix pack-objects to behave the way JGit does, cluster commits first in
the pack stream. Now you have a dense space of commits. If I remember
right this has a tiny positive improvement for most rev-list
operations with very little downside.
> 4. Making a new index version that stores the sha1s separated by type.
> This means we can piggy-back on the regular index to get a packed
> list of just commits. But it also means that regular sha1 lookups
> of the objects have to look in several places (unless the caller
> annotates the call to read_sha1_object with "I am expecting this
> sha1 to be a commit"). And of course it means bumping the index
> version, which is a pain. The external index means it can be
> completely optional on top of the current index/pack.
I don't think this is worthwhile.
>> Depending on the use case, we could just generate packv4-like cache
>> for recently-used trees only. I'm not sure how tree cache impact a
>> merge operation on a very large worktree (iow, a lot of trees
>> referenced from HEAD to be inflated). This is something a cache can
>> do, but a new pack version cannot.
>
> I do not care too much about the cost of running merge on a large
> working tree. Of course it's better to make our optimizations as
> generally applicable as possible, but there is a lot of other work going
> on in a merge. The really painful, noticeable, repetitive bits right now
> are:
>
> 1. Running git-prune.
>
> 2. Creating a pack from git-upload-pack.
>
> Which are both just reachability problems. Something like "git log --
> <pathspec>" would also be helped by packv4-ish tree access patterns,
> though, but not by reachability bitmaps. And that may be something
> worth caring about.
blame would also benefit from a packv4-ish tree.
But upload-pack and prune can make massive improvements through
bitmaps, while packv4-ish tree would be only a marginal incremental
improvement. In the case of upload-pack having a bitmap gives you much
more knowledge of the remote's have set, and allows making a smaller
pack, in a lot less time, and a smaller server memory footprint. Now
that we have implemented bitmaps in our servers, I can say you really
don't want to ignore the gains we can get from them. packv4-ish tree
might help some other workloads, but bitmaps provide a better solution
to these reachability problems than anything else we know.
>> Yes. And if narrow clone ever comes, which needs --objects limited by
>> pathspec, we could just produce extra bitmaps for frequently-used
>> pathspecs and only allow narrow clone with those pathspecs.
>
> I hadn't thought about that. But yeah, because of the optional, external
> nature, there's no reason you couldn't have extra bitmap sets for
> specialized situations.
Right. We still need to redo the JGit patch series to eject the
bitmaps into an extension file. :-(
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Jason Holden @ 2012-12-31 18:22 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121231T103639-635@post.gmane.org>
On Mon, Dec 31, 2012 at 09:40:19AM +0000, Thomas Ackermann wrote:
> Junio C Hamano <gitster <at> pobox.com> writes:
>
> >
> > Thanks; I just realized that nothing in Documentation/ hierarchy
> > mentions these; they are only mentioned in "A Note from the
> > Maintainer" I send out every once in a while (kept in MaintNotes of
> > 'todo' branch):
> >
>
> Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?
>
> ---
> Thomas
Putting it in Documentation/ would add one more outlier file (Along w/
SubmittingPatches and CodingGuidelines). Documentation/technical seems
too deep. I've got a patch that incorporates the content into the
existing README, but that seems a bit out of place, as the previous content of
README was primarily pointers to other docs.
What about a README.developers at the toplevel?
^ permalink raw reply
* Re: git filter-branch doesn't dereference annotated tags
From: Junio C Hamano @ 2012-12-31 18:31 UTC (permalink / raw)
To: Grégory Pakosz; +Cc: git
In-Reply-To: <CAC_01E174m_6tDwPKZ5P0BUxnLNWUf9p+VkECFosPTzip0sYsA@mail.gmail.com>
Grégory Pakosz <gpakosz@visionobjects.com> writes:
> 1) either make git-filter-branch dereference annotated tags and do
> the verification itself then use the two arguments version of git
> update-ref
> 2) in the case of an annotated tag, pass another <old value> to git update-ref
>
> Please find below a patch that implements solution 1).
> ...
> echo "Ref '$ref' was deleted"
> - git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
> + test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git
> update-ref -m "filter-branch: delete" -d "$ref" ||
Thanks. A few comments.
At the design level. Where does this $sha1 come from in the first
place? If a ref that named the annotated tag was deleted, shouldn't
we arrange things so this part of the code receives the $sha1 of the
tag that corresponds to the $ref so that "update-ref -d" can check
that nobody tampered with the repository while the script was
working?
At the implementation level. When the ref being deleted pointed at
a tree or a blob, the original would have correctly removed it, but
will the updated one?
^ permalink raw reply
* Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
From: Junio C Hamano @ 2012-12-31 18:32 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <loom.20121231T103639-635@post.gmane.org>
Thomas Ackermann <th.acker@arcor.de> writes:
>> Thanks; I just realized that nothing in Documentation/ hierarchy
>> mentions these; they are only mentioned in "A Note from the
>> Maintainer" I send out every once in a while (kept in MaintNotes of
>> 'todo' branch):
>
> Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?
Perhaps. It started as a living document that discusses the state
of affairs as of the time of posting (there are mentions to "the
most recent such release was ...", etc), and because I wanted to
keep it that way (and also I needed somewhere to keep track of it),
I deliberately kept it outside the source tree.
It is an addendum to howto-maintain-git, and what it covers overlaps
with it, so it will need some clean-ups if we want to go the route
you suggest.
Having said all that, I think it is still a good idea to keep the
occasional "A note from he Maintainer" posting on list, and a
version that needs to rever to another document after losing
overlaps with howto-maintain-git will no longer will be suitable
source for it, so...
^ permalink raw reply
* [PATCH] merge --no-edit: do not add comments meant for "--edit" mode
From: Junio C Hamano @ 2012-12-31 18:33 UTC (permalink / raw)
To: git
The credit lines "By" and "Via" to credit authors and committers for
their contributions on the side branch are meant as a hint to the
integrator to decide whom to mention in the log message text. After
the integrator saves the message in the editor, they are meant to go
away and that is why they are commented out.
When a merge is recorded without editing the generated message,
however, its contents do not go through the normal stripspace()
and these lines are left in the merge.
Stop producing them when we know the merge is going to be recorded
without editing, i.e. when --no-edit is given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin.h | 3 ++-
builtin/fmt-merge-msg.c | 21 ++++++++++++++-------
builtin/merge.c | 1 +
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/builtin.h b/builtin.h
index dffb34e..3ad8d19 100644
--- a/builtin.h
+++ b/builtin.h
@@ -16,7 +16,8 @@ extern const char git_more_info_string[];
extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
- unsigned add_title:1;
+ unsigned add_title:1,
+ credit_people:1;
int shortlog_len;
};
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 2c4d435..dd1f363 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -232,8 +232,9 @@ static void record_person(int which, struct string_list *people,
{
char *name_buf, *name, *name_end;
struct string_list_item *elem;
- const char *field = (which == 'a') ? "\nauthor " : "\ncommitter ";
+ const char *field;
+ field = (which == 'a') ? "\nauthor " : "\ncommitter ";
name = strstr(commit->buffer, field);
if (!name)
return;
@@ -323,7 +324,8 @@ static void add_people_info(struct strbuf *out,
static void shortlog(const char *name,
struct origin_data *origin_data,
struct commit *head,
- struct rev_info *rev, int limit,
+ struct rev_info *rev,
+ struct fmt_merge_msg_opts *opts,
struct strbuf *out)
{
int i, count = 0;
@@ -335,6 +337,7 @@ static void shortlog(const char *name,
int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
struct strbuf sb = STRBUF_INIT;
const unsigned char *sha1 = origin_data->sha1;
+ int limit = opts->shortlog_len;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
@@ -351,13 +354,15 @@ static void shortlog(const char *name,
if (commit->parents && commit->parents->next) {
/* do not list a merge but count committer */
- record_person('c', &committers, commit);
+ if (opts->credit_people)
+ record_person('c', &committers, commit);
continue;
}
- if (!count)
+ if (!count && opts->credit_people)
/* the 'tip' committer */
record_person('c', &committers, commit);
- record_person('a', &authors, commit);
+ if (opts->credit_people)
+ record_person('a', &authors, commit);
count++;
if (subjects.nr > limit)
continue;
@@ -372,7 +377,8 @@ static void shortlog(const char *name,
string_list_append(&subjects, strbuf_detach(&sb, NULL));
}
- add_people_info(out, &authors, &committers);
+ if (opts->credit_people)
+ add_people_info(out, &authors, &committers);
if (count > limit)
strbuf_addf(out, "\n* %s: (%d commits)\n", name, count);
else
@@ -635,7 +641,7 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
for (i = 0; i < origins.nr; i++)
shortlog(origins.items[i].string,
origins.items[i].util,
- head, &rev, opts->shortlog_len, out);
+ head, &rev, opts, out);
}
strbuf_complete_line(out);
@@ -690,6 +696,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !message;
+ opts.credit_people = 1;
opts.shortlog_len = shortlog_len;
ret = fmt_merge_msg(&input, &output, &opts);
diff --git a/builtin/merge.c b/builtin/merge.c
index e81fde6..c5d3551 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1324,6 +1324,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !have_message;
opts.shortlog_len = shortlog_len;
+ opts.credit_people = (0 < option_edit);
fmt_merge_msg(&merge_names, &merge_msg, &opts);
if (merge_msg.len)
--
1.8.1.rc3.236.g505e3af
^ permalink raw reply related
* Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
From: Jason Holden @ 2012-12-31 18:46 UTC (permalink / raw)
To: git
In-Reply-To: <20121231042736.GA14921@iris.ozlabs.ibm.com>
On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote:
>
> Thanks for the patch. I have a couple of comments about it. First,
> the exec command waits for the process to complete, which means that
> the initial gitk GUI will be unresponsive until the user quits the
> gitk window showing the merge, which could be quite confusing for the
> user.
Good catch. Adding an ampersand on to the exec looks like it fixes
the unresponsiveness. Any issues with that approach?
>
> Secondly, gitk already has support for showing multiple views of a
> repository, that is, different subsets of the commits. Wouldn't it be
> much better to have your new menu item simply create a new view
> showing the merge, rather than creating a whole new window?
I've found when using this feature that I tend to use it in a stack-like
fashion. I tend to want to "push" a merge-view onto the stack, investigate
that view of history for a bit, then "pop" back to my old view. But
you're correct that you can end up with a lot of windows pretty quick.
Any support for stack-like views in the current gui that I missed?
I've got another feature brewing, similiar to the merge-view, where you can
right-click on a file and a new window pops up with the history of just that
file. I tend to use that feature in a stack-like fashion as well.
Maybe the seperate-window/new-view-in-same-window should be a new user
preference?
^ permalink raw reply
* [PATCH v2 0/2] Add MAINTAINERS file and clarify gui workflows
From: Jason Holden @ 2012-12-31 22:19 UTC (permalink / raw)
To: git; +Cc: gitster, th.acker, paulus, patthoyts, worldhello.net,
Jason Holden
Changes since the initial version:
-Added git-po to the MAINTAINERS file and generalized wording that had been
gui-specific
-Fixup some trailing whitespace warnings
Jason Holden (2):
Add top-level maintainers file with email/canonical repository
information
Provide better guidance for submitting patches against upstream
utilities
Documentation/SubmittingPatches | 11 +++++++++++
MAINTAINERS | 21 +++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 MAINTAINERS
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply
* [PATCH v2 1/2] Add top-level maintainers file with email/canonical repository information
From: Jason Holden @ 2012-12-31 22:19 UTC (permalink / raw)
To: git; +Cc: gitster, th.acker, paulus, patthoyts, worldhello.net,
Jason Holden
In-Reply-To: <1356992375-11116-1-git-send-email-jason.k.holden.swdev@gmail.com>
Certain parts of git have a semi-formalized workflow for
incoming patches. This file documents the maintainers, their area of
specialization, their email address, and their canonical repository against
which patches should be submitted.
Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
MAINTAINERS | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000..c3a96b4
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,21 @@
+Core Git/Overall Maintainer:
+ Junio C Hamano <gitster@pobox.com>
+ git://git.kernel.org/pub/scm/git/git.git
+
+
+Certain utilities packaged with git (git-gui, gitk, and git-po) are maintained
+upstream of the core git repository. Their contact information
+and canonical repositories are below. Patches to improve these utilities
+should be made against the tree's referenced below
+
+gitk:
+ Paul Mackerras <paulus@samba.org>
+ git://ozlabs.org/~paulus/gitk
+
+git-gui:
+ Pat Thoyts <patthoyts@users.sourceforge.net>
+ git://repo.or.cz/git-gui
+
+git-po:
+ Jiang Xin <worldhello.net@gmail.com>
+ https://github.com/git-l10n/git-po/
--
1.8.1.rc3.28.g0ab5d1f
^ permalink raw reply related
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