* Re: Improve tags
From: Etienne Vallette d'Osia @ 2009-03-27 14:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Etienne Vallette d'Osia, Michael J Gruber, git
In-Reply-To: <m3bprn2gs7.fsf@localhost.localdomain>
on 27.03.2009 15:15, Jakub Narebski wrote:
> More seriously: take a look at 'notes' idea; I'm not sure what state
> they are currently, but they are in active (more or less) development.
> They are extension of tags, allowing post-fact annotation of commits.
>
git notes store a message related to _a specific_ commit.
It doesn't allow to find some commits.
In my mind, the best way to bind labels and notes (which would be great)
is to allow to create a note related to a label.
Regards,
--
Etienne Vallette d'Osia
^ permalink raw reply
* Re: [PATCH] Two RPM building improvements
From: Michael J Gruber @ 2009-03-27 14:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Niels Basjes, git
In-Reply-To: <m3k56b2hy2.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 27.03.2009 14:50:
> Niels Basjes <Niels@Basjes.nl> writes:
>
>> Two RPM building improvements:
>
> Two _unrelated_ RPM building improvements squashed in one commit.
>
>> - Building the RPMs can now be done by a non-root user.
>
> It was always possible, you only have to configure rpm / rpmbuild,
> namely put path to where you want your RPM_BUILDING directory in
> ~/.rpmmacros as %_topdir, for example:
>
> $ cat ~/.rpmmacros
> %_topdir /home/local/builddir
>
> Please RTFM first, before going to solve non-problem in (ugh) fairly
> complicated way.
Also, the "solution" from the patch overrides any user choice from
.rpmmacros, AFAICS.
>
>> - The additional target all-rpms now builds the RPMs for a multitude of target platforms.
>
> Please wrap commit messages at 72-76 columns, at most at 80 columns.
> No such overly long lines, please.
>
> But the all-rpms target looks like a good idea
>
^ permalink raw reply
* Re: [RFC] Interactive difftool
From: David Aguilar @ 2009-03-27 14:51 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320903260829j34d8c613wf9b4fcc954c8519a@mail.gmail.com>
On 0, Ping Yin <pkufranky@gmail.com> wrote:
> Before git-difftool goes to master, i want to propose a new feature to
> add to or replace the current behaviour of difftool. With current
> difftool, we can only see the diff one by one. However, sometimes what
> we want is to see the diff of selected files, or in a different order,
> just like what we can do in the gui. So here is what i propose
>
> $ git difftool --interactive [options]
> [1] diff.c | 10 +++++++++-
> [2] t/t4020-diff-external.sh | 8 ++++++++
> Choose the file you want to see the diff of: 2
>
> When the user types 2 and then <enter>, the external diff program is called
>
> Further more, instead of just type a number, a letter can be prepended
> to the number to represent different ways of diff. For example
>
> t2 (tool 2): see the diff for file 2 with the configured diff tool
> p2 (patch 2): see the diff for file 2 in the patch format
>
> What do you think?
>
> Ping Yin
That would be pretty cool. I don't know about the
merge-to-master timing and whether we'd want to include new
features before the move.
I guess most of the work would have to be done in
git-difftool-helper.sh. I had a co-worker that asked for this
exact feature just the other day (and ditto for mergetool).
Patches are welcome if you have an idea for how it could work.
Right now we get called indirectly by git-diff so I
don't know if there's an easy way to hook into it like that.
It might be a matter of changing git-difftool.perl so that it
does more of the dispatching itself.
--
David
^ permalink raw reply
* Re: patch series starting with [JGIT PATCH 1/5] Remove dead/unused reset method from CountingOutputStream
From: Shawn O. Pearce @ 2009-03-27 14:51 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <200903270911.54571.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> More related, I also noted that the git:// ssh or file: clone calculates the CRC's separately
> and wasn't subject to this bug.
clone (or fetch) is going through IndexPack, which has its own logic
to tear apart a pack file and build up the table of contents of
that pack in the most efficient method possible. Its an entirely
different code base than writing a pack, because its going the
other direction. :-)
The new test case at least validates that both IndexPack and
PackWriter produce the same information in the .idx file.
--
Shawn.
^ permalink raw reply
* Re: patch series starting with [JGIT PATCH 1/5] Remove dead/unused reset method from CountingOutputStream
From: Shawn O. Pearce @ 2009-03-27 14:55 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <200903270911.54571.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> Seems fine. While verifying this I got this error.
>
> jgit push sftp://me@calhost/home/me/tmp/cb/.git master:master
>
> Counting objects: 20464
> Compressing objects: 100% (20464/20464)
> Writing objects: 100% (20464/20464)
> fatal: Can't write /home/me/tmp/cb/.git/objects/../HEAD: Failure
> fatal: sftp://me@localhost/home/me/tmp/cb/.git: cannot create HEAD
I can't reproduce this error with sftp://.
At first, it failed to push because my target directory didn't exist.
After I made the target directory, I also had to create below it
"refs", "objects", "objects/pack" in order to get the push to
succeed, and then it went through clean.
--
Shawn.
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jakub Narebski @ 2009-03-27 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0902171745320.6185@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
>
> As most of you probably did not find my blog yet, this may come as a
> surprise to you, but it will not be the only surprise in this email.
[...]
Not exactly UGFWIINI yet, but:
"Music collaboration via git?"
http://www.37signals.com/svn/posts/1655-music-collaboration-via-git
(sharing LilyPond source files for music notation).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Interactive difftool
From: Ping Yin @ 2009-03-27 15:23 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List
In-Reply-To: <20090327145122.GA944@gmail.com>
On Fri, Mar 27, 2009 at 10:51 PM, David Aguilar <davvid@gmail.com> wrote:
> On 0, Ping Yin <pkufranky@gmail.com> wrote:
>> Before git-difftool goes to master, i want to propose a new feature to
>> add to or replace the current behaviour of difftool. With current
>> difftool, we can only see the diff one by one. However, sometimes what
>> we want is to see the diff of selected files, or in a different order,
>> just like what we can do in the gui. So here is what i propose
>>
>> $ git difftool --interactive [options]
>> [1] diff.c | 10 +++++++++-
>> [2] t/t4020-diff-external.sh | 8 ++++++++
>> Choose the file you want to see the diff of: 2
>>
>> When the user types 2 and then <enter>, the external diff program is called
>>
>> Further more, instead of just type a number, a letter can be prepended
>> to the number to represent different ways of diff. For example
>>
>> t2 (tool 2): see the diff for file 2 with the configured diff tool
>> p2 (patch 2): see the diff for file 2 in the patch format
>>
>> What do you think?
>>
>> Ping Yin
>
> That would be pretty cool. I don't know about the
> merge-to-master timing and whether we'd want to include new
> features before the move.
>
> I guess most of the work would have to be done in
> git-difftool-helper.sh. I had a co-worker that asked for this
> exact feature just the other day (and ditto for mergetool).
>
> Patches are welcome if you have an idea for how it could work.
> Right now we get called indirectly by git-diff so I
> don't know if there's an easy way to hook into it like that.
> It might be a matter of changing git-difftool.perl so that it
> does more of the dispatching itself.
>
We can just change git-difftool.perl
The easiest way is first parsing the output of git diff --stat,
adding the number at the beginning, for example
[1] diff.c | 10 +++++++++-
[2] t/t4020-diff-external.sh | 8 ++++++++
When the user types a number, git-difftool-helper is launched to show
the diff for the corresponding file.
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: Jakub Narebski @ 2009-03-27 15:59 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1237803348-9329-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> This adds an extended revision syntax to git-difftool.
> Users often ask "how do I compare a file against its
> previous version" and the answer is typically a combination
> of 'git log <file>' and 'git difftool <sha1> <sha1> <file>'.
>
> This makes answering that question considerably easier.
> Users can now simply say:
>
> $ git difftool <file>~
>
> to compare <file> in the worktree against its
> previous version, and:
>
> $ git difftool <file>~2 <file>~
>
> to compare <file> from 2 versions ago to <file>'s
> previous version, etc.
Because <rev>~<n> means (see git-rev-parse(1) for example) n-th parent
in _first parent_ line, then <file>~<n> should also use first-parent
line, otherwise you invite confusion.
Also I am not sure about the syntax, as there are no restrictions on
filenames, and filenames can contain '~'. Perhaps (proposed in this
thread) ~<n>:<file> ==
"$(git rev-list -n <n> --first-parent HEAD -- <file> | tail):<file>"
But this might be mistaken for HEAD~<n>:<file>, which can be something
else...
> The extended revision syntax also expands revisions
> that are suffixed with '!' as a convenient way to
> see commit diffs. Specifying only '!' is equivalent
> to specifying 'HEAD!'.
>
> This makes the following statements equivalent:
>
> $ git difftool !
> $ git difftool HEAD!
> $ git difftool HEAD~ HEAD
Errr... there already exists such syntax, and it is called HEAD^!
(if git-difftool can accept a..b revision specification)... or not,
as git-rev-parse(1) states:
r1^! includes commit r1 but excludes all of its parents.
So depending on how "r1 --not r1^" and "r1 --not r1^1 r1^2" is
interpreted by diff (which accpets points, not ranges) it might be, or
might be not what you wanted by introducying '!' / <rev>:!
specification...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Merge format documented?
From: Jakub Narebski @ 2009-03-27 16:05 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903230419.50000.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Hello,
>
> is the format that git normally uses for indicating merge conflicts in files
> (the <<< === >>> markers) documented somewhere? How exactly does it differ
> from the diff3 format (<<< ||| === >>>)? Diff3's -m mode seems to come close
> to what git does, except that git doesn't produce the ||| section:
It is rcmerge / merge from RCS / CVS output format (and I think it is
also format used for other VCS), and IIRC it is equivalent to "diff3
-E" format
> Does git ever output a ||| section?
You can ask for it with merge.conflictstyle configuration variable, or
--conflict=<style> option to git-checkout.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Two RPM building improvements
From: Niels Basjes @ 2009-03-27 16:07 UTC (permalink / raw)
To: git
Hi Jakub,
----- Jakub Narebski <jnareb@gmail.com> wrote:
> Niels Basjes <Niels@Basjes.nl> writes:
>
> > Two RPM building improvements:
> Two _unrelated_ RPM building improvements squashed in one commit.
Hmm, well, ok. You're right.
> > - Building the RPMs can now be done by a non-root user.
>
> It was always possible, you only have to configure rpm / rpmbuild,
> namely put path to where you want your RPM_BUILDING directory in
> ~/.rpmmacros as %_topdir, for example:
>
> $ cat ~/.rpmmacros
> %_topdir /home/local/builddir
Yes, you're right. It has always been possible.
That works fine if you want all RPMS of multiple project to be thrown
in one heap and have to spent time figuring out which rpms were built by
which project.
I've always preferred forcing the rpmbuilding to be done in a subdirectory
of the current source checkout. That way I can easily remove all old stuff
of _this_ project (simply remove the entire subdirectory) and easily know
what has been created by this project.
> Please RTFM first,
I read the RTFM (really I did).
> before going to solve non-problem in (ugh) fairly complicated way.
What makes this complicated?
It's only different from what you're used to.
> > - The additional target all-rpms now builds the RPMs for a
> > multitude of target platforms.
>
> Please wrap commit messages at 72-76 columns, at most at 80 columns.
> No such overly long lines, please.
Ok.
> But the all-rpms target looks like a good idea
Ok, discard this patch. I'll submit new (splitout) patches.
--
Met vriendelijke groeten,
Niels Basjes
ir. drs. Niels Basjes - http://niels.basj.es/ - VCV 20000302
mailto:`echo 'Niels Basjes'|sed 's/\(.*\)\(..\)/\1.\2/g;s/ /@/g'`
^ permalink raw reply
* Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked
From: Junio C Hamano @ 2009-03-27 16:20 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Daniel Barkalow, Johannes Schindelin
In-Reply-To: <49CC9285.407@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 27.03.2009 09:08:
> ...
>> After calling r-f-t, because this new code assumes that for the "." remote
>> (aka "local repository"), r-f-t lies and does not give back what it
>> expects, fixes what it got back from r-f-t. Shouldn't we be fixing this
>> inside r-f-t?
>
> The technical reason is that there is no local remote, i.e. no remote
> struct for '.', and I don't think we want it, because it would show up
> in all places where the list of remotes is searched/displayed/...
>
> With ret being the branch we talk about, r-f-t is passed ret->remote and
> ret->merge[i] only. In the local case, r-f-t cannot use the remote
> struct for '.' (there is none) to find what it needs, and it has no easy
> access to ret->merge_names[i] which is that info.
>
> branch_get(), on the other hand, has all needed info in place.
Thanks for a detailed explanation. Would it deserve to be in the commit
log justification in a summarized form?
> ..., even worse: if foo is
> ambiguous because refs/heads/foo and refs/remotes/foo exist then
> refs/heads/foo would win, i.e. we used to output the *wrong* ref. The
> above disambiguates. But I'll see if I can simplify the output based on
> the necessity of disambiguation.
Thanks.
^ permalink raw reply
* Re: [PATCH] Two RPM building improvements
From: Junio C Hamano @ 2009-03-27 16:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Niels Basjes, git
In-Reply-To: <m3k56b2hy2.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Niels Basjes <Niels@Basjes.nl> writes:
>
>> Two RPM building improvements:
>
> Two _unrelated_ RPM building improvements squashed in one commit.
>
>> - Building the RPMs can now be done by a non-root user.
>
> It was always possible, you only have to configure rpm / rpmbuild,
> namely put path to where you want your RPM_BUILDING directory in
> ~/.rpmmacros as %_topdir, for example:
>
> $ cat ~/.rpmmacros
> %_topdir /home/local/builddir
>
> Please RTFM first, before going to solve non-problem in (ugh) fairly
> complicated way.
That might be a bit too harsh to somebody who genuinely wished to share
his improvement with others.
Being RPM novice, the first thing I asked around immediately after taking
the maintainership over was the ~/.rpmmacros trick. We really should
mention it in _our_ documentation, even just a sentence or two would be
sufficient.
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: David Aguilar @ 2009-03-27 16:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: gitster, git, spearce
In-Reply-To: <m33acz2byv.fsf@localhost.localdomain>
On 0, Jakub Narebski <jnareb@gmail.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
> > This adds an extended revision syntax to git-difftool.
> > Users often ask "how do I compare a file against its
> > previous version" and the answer is typically a combination
> > of 'git log <file>' and 'git difftool <sha1> <sha1> <file>'.
> >
> > [snip]
> >
> > The extended revision syntax also expands revisions
> > that are suffixed with '!' as a convenient way to
> > see commit diffs. Specifying only '!' is equivalent
> > to specifying 'HEAD!'.
> >
> > This makes the following statements equivalent:
> >
> > $ git difftool !
> > $ git difftool HEAD!
> > $ git difftool HEAD~ HEAD
>
> Errr... there already exists such syntax, and it is called HEAD^!
Yup, this patch was a mistake ;)
^! does exactly what I needed and difftool supports it since
git-diff does.
I'm still interested in the file~<n> idea [though maybe not
that exact syntax] and have been reading revision.c (as Junio
suggested) to see if it can be done in a good way.
I'm still not sure if it is a good idea since the types of
users who would want it are probably better off with tighter
integration between gitk and difftool as opposed to a
convenient command-line syntax (tho I do see how it would be
useful every now and then). Ideally, we'd want to select two
commits in gitk and compare them. I think qgit can do that,
but it doesn't yet know about difftool (since, of course,
difftool is not in master yet).
I noticed that my patches for "add tests to difftool" and "add
the -y shortcut for --no-prompt" were in git.git's pu branch
the other day but aren't there anymore. Was that intentional?
> (if git-difftool can accept a..b revision specification)... or not,
> as git-rev-parse(1) states:
>
> r1^! includes commit r1 but excludes all of its parents.
>
> So depending on how "r1 --not r1^" and "r1 --not r1^1 r1^2" is
> interpreted by diff (which accpets points, not ranges) it might be, or
> might be not what you wanted by introducying '!' / <rev>:!
> specification...
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
--
David
^ permalink raw reply
* Re: [PATCH 2/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-03-27 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow, Johannes Schindelin
In-Reply-To: <7v1vsjey3s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.03.2009 17:20:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Junio C Hamano venit, vidit, dixit 27.03.2009 09:08:
>> ...
>>> After calling r-f-t, because this new code assumes that for the "." remote
>>> (aka "local repository"), r-f-t lies and does not give back what it
>>> expects, fixes what it got back from r-f-t. Shouldn't we be fixing this
>>> inside r-f-t?
>>
>> The technical reason is that there is no local remote, i.e. no remote
>> struct for '.', and I don't think we want it, because it would show up
>> in all places where the list of remotes is searched/displayed/...
>>
>> With ret being the branch we talk about, r-f-t is passed ret->remote and
>> ret->merge[i] only. In the local case, r-f-t cannot use the remote
>> struct for '.' (there is none) to find what it needs, and it has no easy
>> access to ret->merge_names[i] which is that info.
>>
>> branch_get(), on the other hand, has all needed info in place.
>
> Thanks for a detailed explanation. Would it deserve to be in the commit
> log justification in a summarized form?
You tell me :)
I'm still unsure at times how detailed commit messages should be, but I
take it I should put a shortened version of the above in there.
>
>> ..., even worse: if foo is
>> ambiguous because refs/heads/foo and refs/remotes/foo exist then
>> refs/heads/foo would win, i.e. we used to output the *wrong* ref. The
>> above disambiguates. But I'll see if I can simplify the output based on
>> the necessity of disambiguation.
>
> Thanks.
I thought about doing the following:
- remove occurences of refs/remotes (like before the patch) and of
refs/heads. That way the output format stays the same, the amiguity
problem is not worsened
- think later/harder about doing this more cleverly. I guess I need to
check the output of dwim_ref, but have to figure out all the input
parameters first...
Michael
^ permalink raw reply
* Re: How to merge by subtree while preserving history?
From: David Reitter @ 2009-03-27 16:56 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090327073847.GE27459@genesis.frugalware.org>
On Mar 27, 2009, at 3:38 AM, Miklos Vajna wrote:
> Now do a 'git log f474c52..52b8ea9' and you'll see the merged commits.
Sure :)
Needless to say, this is not practical and doesn't support people's
workflow.
For simple renames, "git log --follow" helps, but as soon as you want
to do a "diff" in one of the listed revisions, filtering for just this
one file, then history becomes invisible again. Concretely, this
breaks the common workflow with C-x C-v l, then "d" in Emacs.
I'm aware of the content-tracking vs. file-tracking discussion; it's
all fine, except that file names are meaningful meta-data for some
content, at least in some projects. Is there a command that gives me
the diff for a revision pair, restricted to what happened to content
in a given file in the current tree?
> But you are right about that 'git log -- path' will find the merge
> commits only (which is right, as the tree objects are not modified
> when
> merging, just the resulting tree has the original tree in a
> subdirectory).
>
> If this is a one-time operation then I would just use git filter-
> branch
> to move the code to a subdir.
For the record:
In the meantime, I managed to move the original file in the CVS
repository (by just moving all the ",v" files and getting rid of
CVSROOT/history, which doesn't seem needed). The I re-ran cvsimport,
mitigating a bunch of problems with "cvsps". For the record, cvsps /
cvsimport could not handle the case where my repository named "foo"
had a subdirectory also called "foo", in which I moved all the
stuff. I had to rename the directory to "bar". I also had to
delete cvsps's cache file with the -x argument (or delete it from the
surprising location ~/.cvsps).
Then, I merged with "git pull", noting the rev ID before the merge.
Next, I used "git filter-branch" to rename the directory again from
BAR to FOO as follows:
git filter-branch --index-filter \
'git ls-files -s | sed "s-BAR/-FOO/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' <last-rev-before-
merge>..
Finally, I had to "git gc" to prune a 200MB worth of objects (it told
me I had 500k objects overall).
--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
^ permalink raw reply
* Git Download/Bootstrap Suggestion
From: Mike Gaffney @ 2009-03-27 17:09 UTC (permalink / raw)
To: git
I may be missing something, but I would like to request that
http://git-scm.com/download provide a link to a tarball of the actual
git clone of the current repository with the repo parked on the latest
stable. What I mean is that for most of my systems I build git off of
source but I like to be able to just git pull when I want to update
them. Currently what I have to do is
- download the source tarball (or the rpm)
- make it
- install it
- use that git clone the real repo
- checkout the newest tag
- make configure
- configure
- make
- make install
It'd be a lot cooler if I could just wget a full get repo on the latest
tag :)
Just a request, Thanks
-Mike
^ permalink raw reply
* Re: How to merge by subtree while preserving history?
From: Junio C Hamano @ 2009-03-27 17:20 UTC (permalink / raw)
To: David Reitter; +Cc: Miklos Vajna, git
In-Reply-To: <BA69E81F-C93F-4AD8-8486-A27B0A284D9A@gmail.com>
David Reitter <david.reitter@gmail.com> writes:
> ... Is there a command that gives me
> the diff for a revision pair, restricted to what happened to content
> in a given file in the current tree?
You can get a half of it from blame (and I presume the other half by
running the procedure in reverse).
"git blame" has an obscure switch -S that lets you lie about the ancestry
by allowing you to install a graft (this is primarily used by the annotate
operation of git-cvsserver).
Suppose you have revisions A and B, and a lot of code in a file F in the
original revision A migrated to many other places in a later revision B
over time. You want to see where each and every line in F from A ended up
in B.
To compute this, you pretend as if the history originates at B (i.e. B is
the root commit), and A is a direct descendant of it, and blame each and
every line of F in A, with a very agressive setting. E.g.
{
echo $(git rev-parse A) $(git rev-parse B)
echo $(git rev-parse B)
} >tmp-graft
git blame -C -C -C -w -S tmp-graft A -- F
I'll leave it as an exercise to the readers how to compute "where did each
and every line in G in B came from A?"
Note that in order for this to work, it needs a fix to "blame -S" that I
posted about 10 days ago: aa9ea77 (blame: read custom grafts given by -S
before calling setup_revisions(), 2009-03-18); the fix is sitting in 'pu',
because as far as I know nobody has cared about the breakage other than I,
at least until now.
I've attached a script that uses this trick to compute "How much of what
Linus originally wrote still survives." People who attended GitTogether'08
may have seen the result.
---
#!/bin/sh
# How much of the very original version from Linus survive?
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
initial=$(git rev-parse --verify e83c5163316f89bfbde7d9ab23ca2e25604af290) &&
this=$(git rev-parse --verify ${1-HEAD}^0) || exit
tmp="/var/tmp/Linus.$$"
trap 'rm -f "$tmp".*' 0
# We blame each file in the initial revision pretending as if it is a
# direct descendant of the given version, and also pretend that the
# latter is a root commit. This way, lines in the initial revision
# that survived to the other version can be identified (they will be
# attributed to the other version).
graft="$tmp.graft" &&
{
echo "$initial $this"
echo "$this"
} >"$graft" || exit
opts='-C -C -C -w'
git ls-tree -r "$initial" |
while read mode type sha1 name
do
git blame $opts --porcelain -S "$graft" "$initial" -- "$name" |
sed -ne "s/^\($_x40\) .*/\1/p" |
sort |
uniq -c | {
# There are only two commits in the fake history, so
# there won't be at most two output from the above.
read cnt1 commit1
read cnt2 commit2
if test -z "$commit2"
then
cnt2=0
fi
if test "$initial" != "$commit1"
then
cnt_surviving=$cnt1
else
cnt_surviving=$cnt2
fi
cnt_total=$(( $cnt1 + $cnt2 ))
echo "$cnt_surviving $cnt_total $name"
}
done | {
total=0
surviving=0
while read s t n
do
total=$(( $total + $t )) surviving=$(( $surviving + $s ))
printf "%6d / %-6d %s\n" $s $t $n
done
printf "%6d / %-6d %s\n" $surviving $total Total
}
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: Junio C Hamano @ 2009-03-27 17:21 UTC (permalink / raw)
To: David Aguilar; +Cc: Jakub Narebski, gitster, git, spearce
In-Reply-To: <20090327162849.GA2853@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> I'm still interested in the file~<n> idea [though maybe not
> that exact syntax] and have been reading revision.c (as Junio
> suggested) to see if it can be done in a good way.
I'll send a comment in a separate message.
> I noticed that my patches for "add tests to difftool" and "add
> the -y shortcut for --no-prompt" were in git.git's pu branch
> the other day but aren't there anymore. Was that intentional?
Yes, it makes 'pu' not pass the self test.
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: Junio C Hamano @ 2009-03-27 17:36 UTC (permalink / raw)
To: David Aguilar; +Cc: Jakub Narebski, git, spearce, Christian Couder
In-Reply-To: <20090327162849.GA2853@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> I'm still interested in the file~<n> idea [though maybe not
> that exact syntax] and have been reading revision.c (as Junio
> suggested) to see if it can be done in a good way.
Modern git programs use setup_revisions() to parse object names and range
notation given on the command line, and leave results in revs->pending
array. This array holds pointers to "struct object" instances, and they
are often (always?) already parsed. This gives the caller an easy access
to the parse results.
Recently there have been two topics that made me suspect that solving them
cleanly may require breaking this model. I haven't thought things through
for the second one yet, so please do not take this as a criticism or
pointing-out-concrete-problems in the latter series. At least for the
latter one, it is still an unsubstantiated fear.
(1) "The commit that touched this path the last time"
The objective of this extension is to accept a pathspec and come up with
the name of the commit object that touched the given pathspec recently.
There can be some variations to the parameter the feature could take, and
in the most generic form, the query would be:
* set of commits: start digging from these;
* pathspecs: find commits whose change touches some path that matches them;
* N: do not stop at the latest change, but find the Nth one.
I am not good at coming up with a notation, so I'll leave the actual
syntax to other people, but you can say things like:
git diff <<--all, Documentation t, 4>>
git log <<master, Makefile, 10>>..next -- Makefile
The problem with this feature is this. In order to come up with the
answer, you need to internally run:
git rev-list --all -- Documentation t
git rev-list master -- Makefile
and in order to compute this, the revision traversal machinery has to
not only open and parse commit objects but _rewrite_ the parent field of
these commits for history simplification purposes. This is a destructive
operation, and after it comes back, we would need to clean them up by
unparsing these commits so that the original command that asked for its
command line arguments to be parsed can operate correctly.
At least, this can be fixed by unparsing all the objects parsed so far
when the revision command line parser finishes each such argument, and
force the caller parse them again when they read from rev->pending.
(2) "refs/replace/SHA-1 holds name of the object that replaces SHA-1"
The objective of this extension is to generalize the graft mechanism, so
that they can be shared across the usual object transfer mechanism, the
ordinary revision traversal mechanism can honor the replacement just like
they honor grafts file, while reachability machinery used by object
transfer, fsck and prune can ignore the replacement. When refs/replace/A
has value B, a commit C that records A as its parent would behave as if B
is its parent (so "git log C" will show B as the second entry in its
output), while pushing C will notice C's true parent is A and sends A to
the other end. By pushing refs/replace/A to the other end, you can share
the same "fake" history across repositories.
This feature has similar problem as (1). If you say
git rev-list master..next^^
how should next^^ be interpreted? Because it is an input coming from the
user, we may want to honor the "graft/replace", and we need to read and
parse next, next^, and next^^ while possibly reading from refs/replace/
hiearchy. But after getting the end result, the name of the commit object
the notation refers to, we would need to unparse the objects involved so
that the main parts of the command can start from the clean slate.
There are three issues with this:
(1) When you ask for the data for a concrete SHA-1 (i.e. not "next^", but
something like "9856dd811ee0f256d067b89cbccb58d944aa9c8c"), with and
without grafts/replacements, the actual object data changes.
This again needs at least unparsing of all the objects as in the
<<commits, pathspecs, Nth>> case above to deal with.
(2) Depending on the use of grafts/replacements, the interpretation of
"next^^" changes; should we follow the true parenthood, or the
replaced one?
In order to give Porcelains the same freedom to honor or ignore the
replacements, we would eventually need to expose --ignore-replace
option to "git rev-list":
git rev-list --ignore-replace master..next^^
It gets tricky when --ignore-replace should take effect. Before or
after master..next^^ is interpreted?
(3) Depending on the use of replacements, even the type of the object an
extended SHA-1 expression refers to can change. tag-foo may point at
an object 9856dd811ee0f256d067b89cbccb58d944aa9c8c, and without
replacements it may be a commit but the replacement mechanism is
allowed to say it is another tag that points at a commit.
Not that the "replacement" feature is bad, it is just that the feature is
too flexible for the current codebase to handle sanely.
In order to solve these issues safely (not necessarily efficiently nor
cleanly), I think we might need to change the setup_revisions() to:
(1) operate the way it currently does, leaving the parsed objects in
revs->pending;
(2) remember the objects' SHA-1 and flags in the revs->pending array;
(3) discard all parsed objects, as revision traversals may have rewritten
commits for history simplification purposes; and
(4) rebuild revs->pending list by parsing the objects again, using the
SHA-1 values we remembered in step (2)
or something like that.
^ permalink raw reply
* [PATCH v3 2/2] git-clone: Add new option --branch to override initial branch
From: Tor Arne Vestbø @ 2009-03-27 17:45 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes.Schindelin
In-Reply-To: <1238175913-19175-1-git-send-email-tor.arne.vestbo@nokia.com>
The option '--branch' (short -b) allows the user to override the initial
branch created and checked out by git-clone (normally this is the active
branch of the remote repository).
If the selected branch is not found the operation aborts.
The rationale for this option is to allow new users to Git, who might
not be familiar with the concepts of tracking branches versus normal
branches (or even branches at all), to easily clone a repository and
start working on a branch other than the remote's active branch.
Signed-off-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com>
---
The above situation can be found in projects which keep a master branch
for active development, as well as one or more maintenance branches for
released versions of the project. If a user would like to fix a bug for
a released version, he could use the proposed new option and simply do:
$ git clone git://git.foo.com/project.git --branch 1.6
The manual steps to achieve the same thing would be something like:
$ git clone -n git://git.foo.com/project.git # (1)
$ cd project # (2)
$ git checkout -t origin/1.6 # (3)
$ git branch -D master # (4)
A new user to Git might find this list of commands a bit daunting. It
is also somewhat fragile, as running 'git status' after step (2) will
create an index and hence prevent a checkout due to merge conflicts.
(The reason for deleting the master branch in step (4) is to prevent
errors when the user tries to push his changes to the (rebased) 1.6
branch without also rebasing his master branch against origin/master)
Documentation/git-clone.txt | 5 +++
builtin-clone.c | 71 +++++++++++++++++++++++++-----------------
t/t5702-clone-options.sh | 70 ++++++++++++++++++++++++++++++++++++++++--
3 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 95f08b9..e7feb4d 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -119,6 +119,11 @@ then the cloned repository will become corrupt.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name> instead.
+--branch <name>::
+-b <name>::
+ Instead of using the remote repository's active branch as the
+ initial branch, use <name> instead.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 0031b5f..0d03c87 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -69,6 +70,8 @@ static struct option builtin_clone_options[] = {
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
"create a shallow clone of that depth"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "initial remote branch to check out"),
OPT_END()
};
@@ -323,7 +326,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
+ const struct ref *refs, *mapped_refs;
+ const struct ref *remote_head = NULL, *remote_head_points_at = NULL;
+ const struct ref *initial_branch = NULL;
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
@@ -495,46 +500,35 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
remote_head = find_ref_by_name(refs, "HEAD");
- head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
- }
- else {
+ remote_head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
+
+ if (option_branch) {
+ initial_branch = find_ref_by_name_abbrev(refs, option_branch);
+ if (!initial_branch)
+ die("remote has no branch named '%s'.", option_branch);
+ } else {
+ initial_branch = remote_head_points_at;
+ }
+ } else {
warning("You appear to have cloned an empty repository.");
- head_points_at = NULL;
- remote_head = NULL;
option_no_checkout = 1;
if (!option_bare)
install_branch_config(0, "master", option_origin,
"refs/heads/master");
}
- if (head_points_at) {
- /* Local default branch link */
- create_symref("HEAD", head_points_at->name, NULL);
-
+ /* Set up remote HEAD */
+ if (remote_head_points_at) {
if (!option_bare) {
struct strbuf head_ref = STRBUF_INIT;
- const char *head = head_points_at->name;
-
- if (!prefixcmp(head, "refs/heads/"))
- head += 11;
-
- /* Set up the initial local branch */
-
- /* Local branch initial value */
- update_ref(reflog_msg.buf, "HEAD",
- head_points_at->old_sha1,
- NULL, 0, DIE_ON_ERR);
strbuf_addstr(&head_ref, branch_top.buf);
strbuf_addstr(&head_ref, "HEAD");
/* Remote branch link */
create_symref(head_ref.buf,
- head_points_at->peer_ref->name,
+ remote_head_points_at->peer_ref->name,
reflog_msg.buf);
-
- install_branch_config(0, head, option_origin,
- head_points_at->name);
}
} else if (remote_head) {
/* Source had detached HEAD pointing somewhere. */
@@ -542,7 +536,26 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
update_ref(reflog_msg.buf, "HEAD",
remote_head->old_sha1,
NULL, REF_NODEREF, DIE_ON_ERR);
- } else {
+ }
+
+ /* Set up intitial branch and HEAD */
+ if (initial_branch) {
+ create_symref("HEAD", initial_branch->name, NULL);
+
+ if (!option_bare) {
+ const char *head = initial_branch->name;
+
+ if (!prefixcmp(head, "refs/heads/"))
+ head += 11;
+
+ update_ref(reflog_msg.buf, "HEAD",
+ initial_branch->old_sha1,
+ NULL, 0, DIE_ON_ERR);
+
+ install_branch_config(0, head, option_origin,
+ initial_branch->name);
+ }
+ } else if (!remote_head) {
/* Nothing to checkout out */
if (!option_no_checkout)
warning("remote HEAD refers to nonexistent ref, "
@@ -554,6 +567,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
transport_unlock_pack(transport);
if (!option_no_checkout) {
+ const struct ref *checkout_ref = initial_branch ? initial_branch : remote_head;
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
struct unpack_trees_options opts;
struct tree *tree;
@@ -572,8 +586,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
opts.verbose_update = !option_quiet;
opts.src_index = &the_index;
opts.dst_index = &the_index;
-
- tree = parse_tree_indirect(remote_head->old_sha1);
+ tree = parse_tree_indirect(checkout_ref->old_sha1);
parse_tree(tree);
init_tree_desc(&t, tree->buffer, tree->size);
unpack_trees(1, &t, &opts);
@@ -583,7 +596,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
die("unable to write new index file");
err |= run_hook(NULL, "post-checkout", sha1_to_hex(null_sha1),
- sha1_to_hex(remote_head->old_sha1), "1", NULL);
+ sha1_to_hex(checkout_ref->old_sha1), "1", NULL);
}
strbuf_release(&reflog_msg);
diff --git a/t/t5702-clone-options.sh b/t/t5702-clone-options.sh
index 27825f5..08cd8bd 100755
--- a/t/t5702-clone-options.sh
+++ b/t/t5702-clone-options.sh
@@ -6,9 +6,14 @@ test_description='basic clone options'
test_expect_success 'setup' '
mkdir parent &&
- (cd parent && git init &&
- echo one >file && git add file &&
- git commit -m one)
+ (
+ cd parent && git init &&
+ echo one >file && git add file && git commit -m one &&
+ echo two >file && git add file && git commit -m two &&
+ git checkout -b topic &&
+ echo thee >topic-file && git add topic-file && git commit -m three &&
+ git checkout master
+ )
'
@@ -32,4 +37,63 @@ test_expect_success 'redirected clone -v' '
'
+test_expect_success 'clone --branch sets up the correct remote HEAD' '
+
+ git clone --branch=refs/heads/topic parent clone-topic-remote-head &&
+ (cd clone-topic-remote-head && grep master .git/refs/remotes/origin/HEAD)
+
+'
+
+test_expect_success 'clone --branch sets up the correct local branch' '
+
+ git clone --branch=refs/heads/topic parent clone-topic-name &&
+ (cd clone-topic-name && git rev-parse --verify refs/heads/topic)
+
+'
+
+test_expect_success 'clone --branch sets up the correct local HEAD' '
+
+ git clone --branch=refs/heads/topic parent clone-topic-head &&
+ (cd clone-topic-head && grep topic .git/HEAD)
+
+'
+
+test_expect_success 'clone --branch checks out the correct branch' '
+
+ git clone --branch=refs/heads/topic parent clone-topic-checkout &&
+ test -f clone-topic-checkout/topic-file
+
+'
+
+test_expect_success 'clone --branch works with -n' '
+
+ git clone -n --branch=refs/heads/topic parent clone-topic-checkout-n &&
+ ! test -f clone-topic-checkout-n/topic-file
+
+'
+
+test_expect_success 'clone --branch works with detatched remote HEAD' '
+
+ (cd parent && git checkout master~1) &&
+ git clone --branch=refs/heads/topic parent clone-topic-checkout-detatched &&
+ test -f clone-topic-checkout-detatched/topic-file &&
+ (cd parent && git checkout master)
+
+'
+
+test_expect_success 'clone --branch works with invalid remote HEAD' '
+
+ (cd parent && echo "ref: refs/heads/nonexistent" > .git/HEAD) &&
+ git clone --branch=refs/heads/topic parent clone-topic-checkout-nonexistent &&
+ test -f clone-topic-checkout-nonexistent/topic-file &&
+ (cd parent && git checkout master)
+'
+
+test_expect_success 'clone --branch works with abbreviated ref name' '
+
+ git clone --branch=topic parent clone-topic-abbreviated-name &&
+ (cd clone-topic-abbreviated-name && git rev-parse --verify refs/heads/topic)
+
+'
+
test_done
--
1.6.2.GIT
^ permalink raw reply related
* [PATCH v3 0/2] git-clone: Add new option --branch to override initial branch
From: Tor Arne Vestbø @ 2009-03-27 17:45 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes.Schindelin
This mini-series is a continuation of the efforts to add add a new
option to git clone to allow overriding the initial branch.
The previous patch (v2) and discussion can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/111967/focus=111983
With Junios' comments to v2 of my patch here:
http://thread.gmane.org/gmane.comp.version-control.git/111967/focus=111983
I believe I've covered all the issues in the review, but if there's
still issues please let me know and I'll rework the patch.
Best,
Tor Arne
Tor Arne Vestbø (2):
Move find_ref_by_name_abbrev to refs.c so it can be used globally
git-clone: Add new option --branch to override initial branch
Documentation/git-clone.txt | 5 +++
builtin-clone.c | 71 +++++++++++++++++++++++++-----------------
cache.h | 1 +
refs.c | 10 ++++++
remote.c | 10 ------
t/t5702-clone-options.sh | 70 ++++++++++++++++++++++++++++++++++++++++--
6 files changed, 125 insertions(+), 42 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] Move find_ref_by_name_abbrev to refs.c so it can be used globally
From: Tor Arne Vestbø @ 2009-03-27 17:45 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes.Schindelin
In-Reply-To: <1238175913-19175-1-git-send-email-tor.arne.vestbo@nokia.com>
Signed-off-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com>
---
cache.h | 1 +
refs.c | 10 ++++++++++
remote.c | 10 ----------
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index f48e80b..23699a8 100644
--- a/cache.h
+++ b/cache.h
@@ -815,6 +815,7 @@ struct ref {
#define REF_TAGS (1u << 2)
extern struct ref *find_ref_by_name(const struct ref *list, const char *name);
+extern struct ref *find_ref_by_name_abbrev(const struct ref *list, const char *name);
#define CONNECT_VERBOSE (1u << 0)
extern struct child_process *git_connect(int fd[2], const char *url, const char *prog, int flags);
diff --git a/refs.c b/refs.c
index 26b0014..161e053 100644
--- a/refs.c
+++ b/refs.c
@@ -1644,3 +1644,13 @@ struct ref *find_ref_by_name(const struct ref *list, const char *name)
return (struct ref *)list;
return NULL;
}
+
+struct ref *find_ref_by_name_abbrev(const struct ref *list, const char *name)
+{
+ for ( ; list; list = list->next) {
+ if (refname_match(name, list->name, ref_fetch_rules))
+ return (struct ref *)list;
+ }
+ return NULL;
+}
+
diff --git a/remote.c b/remote.c
index e5d6b10..e903b39 100644
--- a/remote.c
+++ b/remote.c
@@ -1220,16 +1220,6 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
return ret;
}
-static const struct ref *find_ref_by_name_abbrev(const struct ref *refs, const char *name)
-{
- const struct ref *ref;
- for (ref = refs; ref; ref = ref->next) {
- if (refname_match(name, ref->name, ref_fetch_rules))
- return ref;
- }
- return NULL;
-}
-
struct ref *get_remote_ref(const struct ref *remote_refs, const char *name)
{
const struct ref *ref = find_ref_by_name_abbrev(remote_refs, name);
--
1.6.2.GIT
^ permalink raw reply related
* Re: [PATCH] difftool: add support for an extended revision syntax
From: David Aguilar @ 2009-03-27 18:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, spearce
In-Reply-To: <7vab76evaj.fsf@gitster.siamese.dyndns.org>
On 0, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
> > I noticed that my patches for "add tests to difftool" and "add
> > the -y shortcut for --no-prompt" were in git.git's pu branch
> > the other day but aren't there anymore. Was that intentional?
>
> Yes, it makes 'pu' not pass the self test.
Oops, was this related to your suggestions about the patch
that added the tests? I sent a v2 patch that included the
fixups. I'll try running the tests when I get back home to my
Linux machine on Monday (I'm currently in Chicago on a trip)
though I'm not sure if I'd be able to reproduce the failure if
it's platform-specific.
Sorry 'bout that.
--
David
^ permalink raw reply
* [PATCH] git-gui: French translation improvements
From: Nicolas Sebrecht @ 2009-03-27 19:11 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Shawn O. Pearce, Nicolas Sebrecht
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
---
po/fr.po | 47 +++++++++++++++++++++++++++--------------------
1 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/po/fr.po b/po/fr.po
index a944ace..c02272e 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -106,7 +106,7 @@ msgstr "Non modifié"
#: git-gui.sh:1821
msgid "Modified, not staged"
-msgstr "Modifié, pas indexé"
+msgstr "Modifié, non indexé"
#: git-gui.sh:1822 git-gui.sh:1830
msgid "Staged for commit"
@@ -171,7 +171,7 @@ msgstr "Branche"
#: git-gui.sh:2286 lib/choose_rev.tcl:548
msgid "Commit@@noun"
-msgstr "Commit"
+msgstr "Commit@@noun"
#: git-gui.sh:2289 lib/merge.tcl:121 lib/merge.tcl:150 lib/merge.tcl:168
msgid "Merge"
@@ -304,7 +304,7 @@ msgstr "Corriger dernier commit"
#: git-gui.sh:2461 git-gui.sh:2825 lib/remote_branch_delete.tcl:99
msgid "Rescan"
-msgstr "Recharger modifs."
+msgstr "Recharger les modifications"
#: git-gui.sh:2467
msgid "Stage To Commit"
@@ -312,11 +312,11 @@ msgstr "Indexer"
#: git-gui.sh:2473
msgid "Stage Changed Files To Commit"
-msgstr "Indexer toutes modifications"
+msgstr "Indexer toutes les modifications"
#: git-gui.sh:2479
msgid "Unstage From Commit"
-msgstr "Désindexer"
+msgstr "Enlever de l'index"
#: git-gui.sh:2484 lib/index.tcl:410
msgid "Revert Changes"
@@ -397,15 +397,15 @@ msgstr "Branche courante :"
#: git-gui.sh:2761
msgid "Staged Changes (Will Commit)"
-msgstr "Modifs. indexées (pour commit)"
+msgstr "Modifications indexées (à commiter)"
#: git-gui.sh:2781
msgid "Unstaged Changes"
-msgstr "Modifs. non indexées"
+msgstr "Modifications non indexées"
#: git-gui.sh:2831
msgid "Stage Changed"
-msgstr "Indexer modifs."
+msgstr "Indexer les modifications"
#: git-gui.sh:2850 lib/transport.tcl:93 lib/transport.tcl:182
msgid "Push"
@@ -485,11 +485,11 @@ msgstr "Revenir à la version de base"
#: git-gui.sh:3169
msgid "Unstage Hunk From Commit"
-msgstr "Désindexer la section"
+msgstr "Enlever la section de l'index"
#: git-gui.sh:3170
msgid "Unstage Line From Commit"
-msgstr "Désindexer la ligne"
+msgstr "Enlever la ligne de l'index"
#: git-gui.sh:3172
msgid "Stage Hunk For Commit"
@@ -711,7 +711,7 @@ msgstr "Nom :"
#: lib/branch_create.tcl:58
msgid "Match Tracking Branch Name"
-msgstr "Trouver nom de branche de suivi"
+msgstr "Correspond au nom de la branche de suivi"
#: lib/branch_create.tcl:66
msgid "Starting Revision"
@@ -780,6 +780,16 @@ msgstr "Toujours (Ne pas faire de test de fusion.)"
msgid "The following branches are not completely merged into %s:"
msgstr "Les branches suivantes ne sont pas complètement fusionnées dans %s :"
+#: lib/branch_delete.tcl:115
+msgid ""
+"Recovering deleted branches is difficult. \n"
+"\n"
+" Delete the selected branches?"
+msgstr ""
+"Il est difficile de récupérer des branches supprimées.\n"
+"\n"
+"Supprimer les branches sélectionnées ?"
+
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -1099,7 +1109,7 @@ msgstr "Standard (rapide, semi-redondant, liens durs)"
#: lib/choose_repository.tcl:508
msgid "Full Copy (Slower, Redundant Backup)"
-msgstr "Copy complète (plus lent, sauvegarde redondante)"
+msgstr "Copie complète (plus lent, sauvegarde redondante)"
#: lib/choose_repository.tcl:514
msgid "Shared (Fastest, Not Recommended, No Backup)"
@@ -1524,12 +1534,10 @@ msgid ""
"\n"
"Compress the database now?"
msgstr ""
-"Ce dépôt comprend actuellement environ %i objets ayant leur fichier "
-"particulier.\n"
+"Ce dépôt comprend actuellement environ %i objets inutilisés.\n"
"\n"
"Pour conserver une performance optimale, il est fortement recommandé de "
-"comprimer la base quand plus de %i objets ayant leur fichier particulier "
-"existent.\n"
+"comprimer la base quand plus de %i objets inutilisés existent.\n"
"\n"
"Comprimer la base maintenant ?"
@@ -1695,7 +1703,7 @@ msgstr "Déverrouiller l'index"
#: lib/index.tcl:287
#, tcl-format
msgid "Unstaging %s from commit"
-msgstr "Désindexation de : %s"
+msgstr "Enlève %s de l'index"
#: lib/index.tcl:326
msgid "Ready to commit."
@@ -1719,8 +1727,7 @@ msgstr "Annuler les modifications dans ces %i fichiers ?"
#: lib/index.tcl:406
msgid "Any unstaged changes will be permanently lost by the revert."
msgstr ""
-"Toutes les modifications non-indexées seront définitivement perdues par "
-"l'annulation."
+"Toutes les modifications non-indexées seront définitivement perdues."
#: lib/index.tcl:409
msgid "Do Nothing"
@@ -1728,7 +1735,7 @@ msgstr "Ne rien faire"
#: lib/index.tcl:427
msgid "Reverting selected files"
-msgstr "Annuler modifications dans fichiers selectionnés"
+msgstr "Révocation en cours des fichiers sélectionnés"
#: lib/index.tcl:431
#, tcl-format
--
1.6.2.1.389.geed1
^ permalink raw reply related
* Re: [PATCH] Two RPM building improvements
From: Michael J Gruber @ 2009-03-27 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Niels Basjes, git
In-Reply-To: <7vvdpvdjj4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.03.2009 17:20:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Niels Basjes <Niels@Basjes.nl> writes:
>>
>>> Two RPM building improvements:
>>
>> Two _unrelated_ RPM building improvements squashed in one commit.
>>
>>> - Building the RPMs can now be done by a non-root user.
>>
>> It was always possible, you only have to configure rpm / rpmbuild,
>> namely put path to where you want your RPM_BUILDING directory in
>> ~/.rpmmacros as %_topdir, for example:
>>
>> $ cat ~/.rpmmacros
>> %_topdir /home/local/builddir
>>
>> Please RTFM first, before going to solve non-problem in (ugh) fairly
>> complicated way.
>
> That might be a bit too harsh to somebody who genuinely wished to share
> his improvement with others.
>
> Being RPM novice, the first thing I asked around immediately after taking
> the maintainership over was the ~/.rpmmacros trick. We really should
> mention it in _our_ documentation, even just a sentence or two would be
> sufficient.
I assumed everyone building rpms would use rpmdev-setuptree from
rpmdevtools, but apparently not ;) I'm not sure whether non-Redhat
rpm-based distros have that, though.
I'm wondering a bit about the all-rpms target. How does this work
without mock? All build requirements installed for all platforms?? I
think it really calls for a mock build/vm (unless i386 on x86_64).
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox