* Using the "What's cooking" scripts outside of Git
From: R. Tyler Ballance @ 2009-01-26 19:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
I was toying around with the idea of generating a "What's cooking" email
similar to Junio's for our internal development, and I'm wondering if
anybody has any experience using the scripts outside of the standard Git
repository.
Our repo is laid out slightly different, there's no "next" branch but
there are a number of "in development" branches that get folded down
into master.
Any tips would be appreciated
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Sverre Rabbelier @ 2009-01-26 19:30 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jakub Narebski, Peter Krefting, Dill, Git Mailing List
In-Reply-To: <20090126162351.GA8911@glandium.org>
On Mon, Jan 26, 2009 at 17:23, Mike Hommey <mh@glandium.org> wrote:
> On the other hand, the people who would really need the translations
> didn't answer the survey at all, since they couldn't read it.
Perhaps the basics can be translated at least, the documents that do
not require much change because they represent stable concepts?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-26 19:29 UTC (permalink / raw)
To: git
Hi,
I'd like to create a branch in a subversion repository so that I can
work with git-svn on it.
My git repository is already with a history, that I don't want to
replicate to subversion, I want to start with subversion having just the
latest revision and then continue from there normally (git svn
dcommit/rebase).
How can I do that?
Thanks,
Ittay
^ permalink raw reply
* Re: [PATCH v2] Allow format-patch to create patches for merges
From: Sverre Rabbelier @ 2009-01-26 19:34 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <1232988212-8613-1-git-send-email-nathan.panike@gmail.com>
On Mon, Jan 26, 2009 at 17:43, Nathan W. Panike <nathan.panike@gmail.com> wrote:
> This seems to solve my problem, but maybe my workflow is sufficiently different
> that it is a problem no one else has. Maybe someone can point me in a direction
> that solves problems more users have.
It seems like you want to use bundles instead of patches? Since you're
using it just to propagate your changes...?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126184829.GA27543@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 1:48 PM, Jeff King <peff@peff.net> wrote:
> But then you have that problem that the _user_ is stuck specifying "OK,
> turn on fancy features." And I don't relish the thought of typing "git
> diff -J" every time. :)
Well, this issue seems to come up every so often, so the idea would be:
- We're adding a mechanism for scripts to communicate that they need
plumbing context
- Start using it in your scripts when calling git if you rely on a
stable interface
- In the next major release, git may introduce changes to commands
which are not clearly plumbing if you haven't adopted the mechanism
Where mechanism could be a switch, environment variable, etc.
Typically in a network API, the client and server have a way to
negotiate the highest level each supports; that's missing from git,
but seems like it would be useful.
j.
p.s. perhaps you'd prefer -P? :)
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0901261100200.5284@localhost.localdomain>
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> On Mon, 26 Jan 2009, Daniel Barkalow wrote:
> >
> > I was just doing an annoying merge (I'd reorganized code while other
> > people made changes to it), and I kept having the problem that it was hard
> > to figure out what each side had done. Is there some way to ask git for
> > the diffs between the common ancestor (which is unique in my case, so it's
> > actually useful) and each of the sides of the merge? Ideally, it would
> > give essentially the converse of the --cc diff: first column is -stage 1
> > +stage 2; second column is -stage 1 +stage 3.
>
> Have you tried "gitk --merge [filename]"?
>
> That's usually even more useful - because it doesn't just give a diff, it
> gives the actual commits that caused the conflict. That way you see what
> both sides of a merge tried to do.. It's what I do when encountering
> conflicts on the kernel (where I'm usually not the author of _either_ side
> of the code that causes a conflict), and it really is very powerful.
That is really nice, and quite handy. I ended up getting approximately
that effect with blame and show, but gitk is much easier. For some reason,
I never think of the graphical tools. Is there an easy way of focusing on
the changes that end up in a particular conflict? Half of the work was
finding the right commit and finding the right part of the diff.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-bundle(1): add no references required simplest case
From: Junio C Hamano @ 2009-01-26 19:53 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, gitster, spearce, git
In-Reply-To: <87d4e97uxb.fsf_-_@jidanni.org>
jidanni@jidanni.org writes:
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> See http://article.gmane.org/gmane.comp.version-control.git/103576
> Documentation/git-bundle.txt | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
> index 1b66ab7..7c1e990 100644
> --- a/Documentation/git-bundle.txt
> +++ b/Documentation/git-bundle.txt
> @@ -164,6 +164,13 @@ $ git pull bundle
> would treat it as if it is talking with a remote side over the
> network.
>
> +If a bundle requires no references, one may simply use:
Two nits.
1. Bundle does not require reference;it requires commits.
2. "One may simply use:" with a recipe without saying what the recipe is
useful for is not very helpful.
The second point needs to be stressed. For example, you could say
something like this:
With any bundle, you may simply say:
$ git ls-remote bundle.bdl
and it is a correct description if it is to see the refs in the bundle is
what you want to do, but it does not help when cloning from it is what you
want.
It would be a good practice to make the new part go with the flow of the
existing examples. Adding the following at the end might be a better way
to do this than your "init then pull" example:
A complete bundle is one that does not require you to have any
prerequiste object for you to extract its contents. Not only you
can fetch/pull from a bundle, you can clone from a complete bundle
as if it is a remote repository, like this:
----------------
$ git clone /home/me/tmp/file.bdl mine.git
----------------
This will define a remote called "origin" in the resulting
repository that lets you fetch and pull from the bundle, just
like the previous example lets you do with the remote called
"bundle", and from then on you can fetch/pull to update the
resulting mine.git repository after replacing the bundle you store
at /home/me/tmp/file.bdl with incremental updates.
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Junio C Hamano @ 2009-01-26 19:55 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge?
Have you tried "git checkout --conflict=diff3 $that_conflicted_path"?
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Dill @ 2009-01-26 19:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <200901261631.18157.jnareb@gmail.com>
I was thinking of handling it like the Linux kernel documentation...?
On 1/26/09, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Peter Krefting wrote:
>> Jakub Narebski wrote:
>>
>> > With GUI translations we just use gettext conventions. I don't know
>> > any such convention for docs:
>>
>> There is a lot of documentation being translated using PO files. po4a -
>> http://po4a.alioth.debian.org/ - is a nice starting point for that.
>
> I'm not sure if XLIFF wouldn't be better format to use to translate
> _documents_. Gettext was meant to translate, I think, not very long
> messages in programs.
>
> Also I am not sure how much support this idea has. True, in last Git
> User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
> was out of 325 people who answered this question, with 3236 responses
> to survey in total, so numbers are more like 6% - 8%.
>
> [1] http://git.or.cz/gitwiki/GitSurvey2008
> [2] http://translate.sourceforge.net/wiki/
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-26 20:02 UTC (permalink / raw)
To: git
I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
does not seem to be set up to do out of tree builds. If that is not
true, please let me know.
The install process wants to call install with a -d option. AIX has
two install programs but they are pretty old -- neither takes a -d
option.
Is there a GNU install program I can get? I've not been able to
locate one.
The curious thing is I installed git 1.5.6.4 on a similar AIX system a
few months ago and succeeded.
Last -- just so I know for future reference, is this list a 'text only
email' list?
Thank you for your help,
Perry
Ease Software, Inc. ( http://www.easesoftware.com )
Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
^ permalink raw reply
* git push --all not so all (was: Re: [ANNOUNCE] conntrack-tools 0.9.10 released)
From: Jan Engelhardt @ 2009-01-26 20:03 UTC (permalink / raw)
To: git; +Cc: Netfilter Developer Mailing List, pablo
In-Reply-To: <497E03E7.7030201@netfilter.org>
On Monday 2009-01-26 19:41, Pablo Neira Ayuso wrote:
>Jan Engelhardt wrote:
>> On Sunday 2009-01-25 22:05, Pablo Neira Ayuso wrote:
>>
>>> Hi!
>>>
>>> The netfilter project presents another development release of the
>>> conntrack-tools. As usual, this release includes important fixes,
>>> improvements and new features, mainly:
>>
>> The git tag for 0.9.10 seems to be missing.
>
>I forgot to add git push --tags to my release scripts, thanks for the
>notice.
I always wonder why `git push --all` does not push everything
(it should be true to its name, really) — such as tags o_O
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Junio C Hamano @ 2009-01-26 20:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Johannes Schindelin, Keith Cascio, git
In-Reply-To: <76718490901261149xfedc415j8f5dab677b90d693@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Mon, Jan 26, 2009 at 1:48 PM, Jeff King <peff@peff.net> wrote:
>> But then you have that problem that the _user_ is stuck specifying "OK,
>> turn on fancy features." And I don't relish the thought of typing "git
>> diff -J" every time. :)
>
> Well, this issue seems to come up every so often, so the idea would be:
>
> - We're adding a mechanism for scripts to communicate that they need
> plumbing context
> - Start using it in your scripts when calling git if you rely on a
> stable interface
> - In the next major release, git may introduce changes to commands
> which are not clearly plumbing if you haven't adopted the mechanism
Where do all of these nonsense come from? We are not adding any mechanism
for scripts to say they need plumbing context. By calling plumbing they
are already asking for stable plumbing behaviour.
The scripts can, if they want to, use newer options updated versions of
the plumbing commands offer, by passing them when they want to.
And the trigger to do so is up to the scripts. They can get new options
from the end user, or they can peek into user's configuration variables
similar to the diff.primer mentioned earlier in the discussion.
One way could be a new option --screw-me-with=name that can be given to a
plumbing command and tells it pretend as if the command line options
specified by the configuration variable of the given name were given
(e.g. a script runs "git diff-files --screw-me-with=diff.primer").
The important point is that it has to be opt _IN_.
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Junio C Hamano @ 2009-01-26 20:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jake Goulding, git
In-Reply-To: <alpine.DEB.1.00.0901261637300.25749@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 26 Jan 2009, Jake Goulding wrote:
>
>> Moving has_commit from branch to a common location in preparation for
>> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
>> unique.
>
> I feel like bike-shedding for a change, and I'd also like to prove that
> not all Germans like long names:
>
> is_ancestor_of_any()
>
> Hmm?
Is it ancestor or descendant? The latter makes the name longer, though
;-)
^ permalink raw reply
* Re: Using the "What's cooking" scripts outside of Git
From: Junio C Hamano @ 2009-01-26 20:15 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1232997904.22352.4041.camel@starfruit>
"R. Tyler Ballance" <tyler@slide.com> writes:
> I was toying around with the idea of generating a "What's cooking" email
> similar to Junio's for our internal development, and I'm wondering if
> anybody has any experience using the scripts outside of the standard Git
> repository.
>
> Our repo is laid out slightly different, there's no "next" branch but
> there are a number of "in development" branches that get folded down
> into master.
UTSL, it's all open source ;-)
It is generated by the toolchain I check out in Meta/ directory from the
'todo' branch of git.git. Of interest would be
- git-topic.perl -- this lists the topics with their doneness. It
unfortunately heavily depends on my workflow to have one stable
('next') and one wilder ('pu') test integration branches, and
convention to name the topics as ??/?*.
- WC -- this produces and helps me maintain "What's cooking". It calls
git-topic.perl to generate the list, and optionally calls UWC to merge
the new one with the previous issue.
- UWC -- this reads the last issue of "What's cooking", and uses the
output from git-topic.perl to update it. It primarily is needed
because the order topics are output from git-topic.perl is different
from how I want to have them listed in "What's cooking", and reads the
last issue to classify each topics into the same category as they
appeared in it.
- WI -- this gives "What's in" and should be straightforward.
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, Keith Cascio, git
In-Reply-To: <7vd4e96dh7.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 26, 2009 at 3:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Where do all of these nonsense come from? We are not adding any mechanism
> for scripts to say they need plumbing context. By calling plumbing they
> are already asking for stable plumbing behaviour.
The suggestion was wrt to commands which are not strictly plumbing.
j.
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Johannes Schindelin, Keith Cascio, git
In-Reply-To: <7vd4e96dh7.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 26, 2009 at 12:04:20PM -0800, Junio C Hamano wrote:
> > Well, this issue seems to come up every so often, so the idea would be:
> >
> > - We're adding a mechanism for scripts to communicate that they need
> > plumbing context
> > - Start using it in your scripts when calling git if you rely on a
> > stable interface
> > - In the next major release, git may introduce changes to commands
> > which are not clearly plumbing if you haven't adopted the mechanism
>
> Where do all of these nonsense come from? We are not adding any mechanism
> for scripts to say they need plumbing context. By calling plumbing they
> are already asking for stable plumbing behaviour.
I think this is my fault a little for mentioning "blurred plumbing and
porcelain" and not explaining further. This really has nothing to do
with actual plumbing commands. Scripts should use diff-tree and not
diff, and that has always and probably will always be the case.
But what about something like "git grep"? Is it plumbing or porcelain?
The functionality isn't exposed in any other way, so I can imagine that
some scripts are using it. But it's sad to think that we could never
have config that might change its behavior, because it is used directly
by users all the time. I think the same applies for "git archive".
There may be others.
So something like Jay's proposal could future-proof those commands
better by allowing scripts to say "BTW, I am a script. Turn off your new
features." And there are two classes of alternatives:
- as you described, instead of making scripts turn _off_ features,
make them turn them _on_, effectively declaring these commands as
plumbing. This is obviously much nicer because it Just Works with
current scripts. But it means that these mixed porcelain/plumbing
commands suffer in their porcelain capacity; we can never add a
config option that might change the behavior without the user
specifying "it's ok to use this feature" at each invocation.
- we can provide support _now_ for splitting the functionality into
porcelain and plumbing, scripts can adapt over time to using the
plumbing version, and then eventually we can declare it safe to make
changes to the porcelain. And that is more or less what Jay's
proposal is doing.
However, I don't think a command-line option is the best way to say
"I am a script". It's too easy to type "git grep" in a script and
"git grep -J" (either because you are clueless about "-J", or
because you simply forget). Other signal methods include:
- just making two different commands to expose the same
functionality, one plumbing and one porcelain. This is what has
evolved in other areas, such as diff (though note that there
_isn't_ exactly a "git diff" plumbing command -- there is the
plumbing that "git diff is based on). I'm not sure what the
plumbing name for "git grep" would be.
- set an environment variable like GIT_STRICT. It's easy to set
once at the top of your script, and it trickles down
automatically as we call other git commands and scripts.
We could even set it in git-sh-setup, though that of course
covers only shell scripts, and not other callers.
> The scripts can, if they want to, use newer options updated versions of
> the plumbing commands offer, by passing them when they want to.
>
> And the trigger to do so is up to the scripts. They can get new options
> from the end user, or they can peek into user's configuration variables
> similar to the diff.primer mentioned earlier in the discussion.
Right, I think that is absolutely the right thing for commands which are
clearly plumbing.
> One way could be a new option --screw-me-with=name that can be given to a
> plumbing command and tells it pretend as if the command line options
> specified by the configuration variable of the given name were given
> (e.g. a script runs "git diff-files --screw-me-with=diff.primer").
>
> The important point is that it has to be opt _IN_.
Our precedent so far has been to just add a new command line option that
enables the feature (e.g., --ext-diff and --textconv). Functionally it
is no different than --screw-me-with=diff.*.textconv. :)
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Johannes Schindelin @ 2009-01-26 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jake Goulding, git
In-Reply-To: <7v63k16dd0.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 26 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 26 Jan 2009, Jake Goulding wrote:
> >
> >> Moving has_commit from branch to a common location in preparation for
> >> using it in tag. Renaming it to commit_has_any_in_commit_list to be
> >> more unique.
> >
> > I feel like bike-shedding for a change, and I'd also like to prove
> > that not all Germans like long names:
> >
> > is_ancestor_of_any()
> >
> > Hmm?
>
> Is it ancestor or descendant? The latter makes the name longer, though
> ;-)
I did not read the patch and missed that it means the opposite, sorry...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Jeff King @ 2009-01-26 20:45 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: Johannes Schindelin, git
In-Reply-To: <d77df1110901260827j2200fe41oe1b84c387d88aba@mail.gmail.com>
On Mon, Jan 26, 2009 at 10:27:18AM -0600, Nathan W. Panike wrote:
> I think I have an unusual workflow where my patch makes sense,
> although it probably does not for the vast majority of git users. I
> regularly use 3 machines: S, L, and H. I keep my work synchronized by
> using git. Normally, I fetch from S to L or to H, depending on which
> machine I am working on at the moment. I also push from L or H to S.
> I sporadically lose connectivity to S, so I have a hook in the repo on
> S to send a backup email to me on mail server M, which has a more
> reliable connection. This email also serves as a reminder when I
Have you considered sending a bundle instead of a patch in the backup
email? That is the more exact equivalent of a push (i.e., it preserves
your actual commits, sha1 and all).
-Peff
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-26 20:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <1232960722-17480-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> From: Junio C Hamano <gitster@pobox.com>
>
> d911d14 (rebase -i: learn to rebase root commit, 2009-01-02) tried to
> remember the --root flag across a merge conflict in a broken way.
> Introduce a flag file $DOTEST/rebase-root to fix and clarify.
>
> While at it, also make sure $UPSTREAM is always initialized to guard
> against existing values in the environment.
>
> [tr: added tests]
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Junio C Hamano wrote:
>> Since you never use the value stored in "$DOTEST/upstream" for anything
>> else anyway, how about doing something like this instead? It would make
>> the meaning of the file used as a state variable much clearer.
>
> Yes, thanks, a patch precisely "like this" is in fact the right fix.
>
> I came up with some tests that try a conflicted --root rebase of each
> flavour, to guard against the problem in the future. I wasn't
> entirely sure how to shape this into a patch, but here's a version
> that forges patch message and sign-off in your name.
>
> Dscho, with that confusion cleared, you can add my Ack to your 1/2
> (unchanged, though I'm afraid you'll get a textual conflict).
Ok, so I'll queue this to 'master' as a bugfix.
Thanks.
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Linus Torvalds @ 2009-01-26 20:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261412110.19665@iabervon.org>
On Mon, 26 Jan 2009, Daniel Barkalow wrote:
>
> That is really nice, and quite handy. I ended up getting approximately
> that effect with blame and show, but gitk is much easier. For some reason,
> I never think of the graphical tools.
You can do the same thing on the command-line with just doing
git log --merge [filename]
but when doing conflict resolution you often do care (deeply) about the
way the commits hang together, so the graphical tools really do end up
giving you fundamentally interesting information that is hard to show in
any readable way with just plain text.
[ Yeah, there's "--graph", but it really loses out on the whole
readability thing ]
> Is there an easy way of focusing on the changes that end up in a
> particular conflict? Half of the work was finding the right commit and
> finding the right part of the diff.
This is where the command line tools really help. What I do is to just
fire up that "gitk" and 90% of the time the thing is clear from that. But
_if_ it then is complex, and has a ton of changes to the same file that
really aren't that interesting, doing a
git log --merge -S'interesting-part-goes-here' [filename]
in another window tends to be a good idea. That way you get the commits
that just touch that string, and you can do the whole 'goto-SHA1' in the
gitk window to see them there.
Sometimes, "git blame -C " is also a good tool to have around. You seem to
have found it already. One usage case is
git blame -C $(git merge-base HEAD MERGE_HEAD).. filename
which then high-lights the lines changed from the merge-base to the HEAD
(change it to "..MERGE_HEAD" to see what changed to MERGE_HEAD), but quite
frankly, I tend to use "git blame" more as a tool _after_ the merge, when
I noticed that I merged things wrong and go back and try to figure out
what caused the problem.
Linus
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Junio C Hamano @ 2009-01-26 20:38 UTC (permalink / raw)
To: Dill; +Cc: Jakub Narebski, Peter Krefting, Git Mailing List, yasuaki_n
In-Reply-To: <60646ee10901261158w65b539dida26d2bd3bae6903@mail.gmail.com>
Dill <sarpulhu@gmail.com> writes:
> On 1/26/09, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 26 Jan 2009, Peter Krefting wrote:
>>> Jakub Narebski wrote:
>>>
>>> > With GUI translations we just use gettext conventions. I don't know
>>> > any such convention for docs:
>>>
>>> There is a lot of documentation being translated using PO files. po4a -
>>> http://po4a.alioth.debian.org/ - is a nice starting point for that.
>>
>> I'm not sure if XLIFF wouldn't be better format to use to translate
>> _documents_. Gettext was meant to translate, I think, not very long
>> messages in programs.
>>
>> Also I am not sure how much support this idea has. True, in last Git
>> User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
>> was out of 325 people who answered this question, with 3236 responses
>> to survey in total, so numbers are more like 6% - 8%.
>>
>> [1] http://git.or.cz/gitwiki/GitSurvey2008
>> [2] http://translate.sourceforge.net/wiki/
>> ...
> I was thinking of handling it like the Linux kernel documentation...?
By this, I understand you mean the model that lets the authors of the
original English documentation be unaware of the presense of translations,
and resulting translated files are placed in Documentation/??_??/ (where
"??_??" are ja_JP, zh_CN, etc.) subdirectory.
The approach obviously risks the translations to go stale very easily, but
gives a nice separation of reponsibility and does not slow down the way
the original documents are updated. I would actually prefer a directory
structure "Documentation/translated/??_??/" so that people who are not
involved in the translation do not have to see anything below _one_
directory (i.e. "translated").
If you step in as the Documentation translation coordinator to maintain
such a tree structure that I can have as a submodule (or subtree merge) to
git.git tree, you could talk me into updating my tree from time to time
from your tree, but at that point we might actually want to have such a
translation project as a separate and unrelated project.
By the way,
http://github.com/yasuaki/git-manual-jp.git/
has some Japanese translations (no, I am not involved in this any way, and
I do not know about its current status).
If you look at files in Documentation/ (not Documentation.ja) in that
repository, you can see how they tried to make it easier to update the
translation to match the original documentation set when the original gets
updated. I do not know how well the approach works in practice, though.
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Jeff King @ 2009-01-26 21:00 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
In-Reply-To: <A8D76E61-4442-4640-BD0C-84085375E6F1@gmail.com>
[cc-ing Mike Ralphson, our local AIX expert]
On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
> does not seem to be set up to do out of tree builds. If that is not
> true, please let me know.
>
> The install process wants to call install with a -d option. AIX has two
> install programs but they are pretty old -- neither takes a -d option.
>
> Is there a GNU install program I can get? I've not been able to locate
> one.
It's in GNU coreutils:
http://www.gnu.org/software/coreutils/
I don't know what Mike uses to install on AIX; you can see his config
setup here:
http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
but I don't see any override of install.
> Last -- just so I know for future reference, is this list a 'text only
> email' list?
If you mean "no html", then yes, it is absolutely text only.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-26 21:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <1232960722-17480-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> +test_expect_success 'rebase -i --root with conflict (first part)' '
> + git checkout -b conflict2 other &&
> + GIT_EDITOR=: test_must_fail git rebase -i --root --onto master &&
> + git ls-files -u | grep "B$"
> +'
Maybe I am misrecalling things but didn't we have reports from people on
some platforms that single-shot exporting of the environment like this one
does not work for them?
> +test_expect_success 'fix the conflict' '
> + echo 3 > B &&
> + git add B
> +'
> +
> +test_expect_success 'rebase -i --root with conflict (second part)' '
> + git rebase --continue &&
> + git log --pretty=tformat:"%s" > conflict2 &&
> + test_cmp expect-conflict conflict2
> +'
> +
> +sed 's/#/ /g' > expect-conflict-p <<'EOF'
> +* Merge branch 'third' into other
> +|\##
> +| * 6
> +* | Merge branch 'side' into other
> +|\ \##
> +| * | 5
> +* | | 4
> +|/ /##
> +* | 3
> +|/##
> +* conflict
> +* 2
> +* 1
> +EOF
I do not like this very much. Future improvements of the graph drawing
algorithm (one obvious "flaw" you are exposing by the above is that it has
trailing whitespaces that can be trimmed, and somebody else may be
inclined to fix) would break the expectation this test vector has.
Do you have to compare the topology this way, or are there other more
reliable ways?
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Jeff King @ 2009-01-26 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Schindelin
In-Reply-To: <7veiyp4w2m.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 26, 2009 at 01:05:37PM -0800, Junio C Hamano wrote:
> > +test_expect_success 'rebase -i --root with conflict (first part)' '
> > + git checkout -b conflict2 other &&
> > + GIT_EDITOR=: test_must_fail git rebase -i --root --onto master &&
> > + git ls-files -u | grep "B$"
> > +'
>
> Maybe I am misrecalling things but didn't we have reports from people on
> some platforms that single-shot exporting of the environment like this one
> does not work for them?
I don't think you are misrecalling. The problem is with one-shot
variables and functional calls. See 09b78bc1.
-Peff
^ permalink raw reply
* Re: rerere: how to remove an erroneous resolution?
From: Jeff King @ 2009-01-26 21:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20090126151326.GA2618@neumann>
On Mon, Jan 26, 2009 at 04:13:26PM +0100, SZEDER Gábor wrote:
> On Mon, Jan 26, 2009 at 03:42:39PM +0100, SZEDER Gábor wrote:
> > some time ago I mistakenly resolved a merge conflict incorrectly. Of
> > course, rerere noted the erroneous conflict resolution, and whenever
> > the same merge conflict occurs rerere offers me that erroneous
> > conflict resolution, even though I correct it each time.
> >
> > So, the question is how could I make rerere forget that particular
> > merge conflict resolution? Is it at all possible?
>
> Ok, I should have investigated a little longer before sending that
> email.
Hmm. I have never actually used rerere in a real setting, so I am
somewhat clueless. But from your description, it sounds like it would
make sense for it to update the resolution to the latest one used. If
you changed it, it was probably to correct it; you would have no need to
make a change to break an already-working resolution.
Then you would not have had to go mucking about in .git.
-Peff
^ 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