ble any history simplification and not limited to
> pathspec limiting (e.g. simplify-by-decoration enables it, too).
>
How about the below patch? I used "can_ignore_commits" as the bit name, which -
as the commit msg states - reflects the terminology used in get_commit_action
Matthew DeVore writes:
> When I tried to figure out what "prune" and "prune_data" ("data" is
> quite vague, so these two fields read like "prune_1" and "prune_2")
> referred to in "revision.h",...
It was unfortunate that 8efdc326 ("rev-lib: Make it easy to do
rename tracking (take 2)", 2006-03-1
On Sat, Dec 8, 2018 at 5:36 PM Junio C Hamano wrote:
>
> Matthew DeVore writes:
>
> > In the codebase, "prune" is a highly overloaded term, and it caused me a
> > lot of trouble to figure out what it meant when it was used in the
> > context of path limiting. Stop using the word "prune" when we r
Junio C Hamano writes:
> AFAIK, "prune" is also used to describe unreachable loose objects,
s/describe/& the act of culling/
> but that use is fairly isolated and have little risk of being
> confusing too much. Are there other uses to make you consider it
> "highly overloaded"?
Matthew DeVore writes:
> In the codebase, "prune" is a highly overloaded term, and it caused me a
> lot of trouble to figure out what it meant when it was used in the
> context of path limiting. Stop using the word "prune" when we really
> mean "path limiting."
path limiting is also used for two
In the codebase, "prune" is a highly overloaded term, and it caused me a
lot of trouble to figure out what it meant when it was used in the
context of path limiting. Stop using the word "prune" when we really
mean "path limiting."
Signed-off-by: Matthew DeVore
---
Documentation/technical/api-his
>> option how to interpret the equivalent rewrite terminology for
>> consistency.
>
> I'm somewhat negative to this patch. IMHO, adding the rewrite modes as
> merge strategy synonyms adds no benefit - only potential confusion -
> to the existing merge strategies. ...
> ..
ality. Teach the -s/--strategy
>> option how to interpret the equivalent rewrite terminology for
>> consistency.
>
> I'm somewhat negative to this patch. IMHO, adding the rewrite modes as
> merge strategy synonyms adds no benefit - only potential confusion -
> to the existin
On Mon, Aug 17, 2015 at 10:46 AM, Jacob Keller wrote:
> From: Jacob Keller
>
> notes-merge.c already re-uses the same functions for the automatic merge
> strategies used by the rewrite functionality. Teach the -s/--strategy
> option how to interpret the equivalent rewrite
From: Jacob Keller
notes-merge.c already re-uses the same functions for the automatic merge
strategies used by the rewrite functionality. Teach the -s/--strategy
option how to interpret the equivalent rewrite terminology for
consistency.
Add tests for the new synonyms.
Teaching rewrite how to
On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:
>>
>> Not sure if German users would know what "hunk" means, in case we
>> leave it untranslated. And I'm not sure if I would understand "Kontext".
>> I tend to leave it untranslated.
>
>Anyone found a German translation of the Patch manpage? T
Hi all,
thanks for all your comments. Here's an updated version of the glossary
including (hopefully) all the changes you've suggested.
Basic repository objects:
blob = Blob
tree = Baum-Objekt (bevorzugt), "Tree"-Objekt
submodule = Submodul
pack(noun)
2013/5/23 Bernhard R. Link :
> * Ralf Thielow [130522 17:17]:
>> >> remote branch = Remote-Branch
>> >> remote-tracking branch = Remote-Tracking-Branch
>> >> upstream branch= Upstream-Branch
>> >
>> > Yes. What's the main reason for using "Branch" in the German text?
* Ralf Thielow [130522 17:17]:
> >> remote branch = Remote-Branch
> >> remote-tracking branch = Remote-Tracking-Branch
> >> upstream branch= Upstream-Branch
> >
> > Yes. What's the main reason for using "Branch" in the German text?
> > Consistency
> > with the command
On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:
>>
>> Not sure if German users would know what "hunk" means, in case we
>> leave it untranslated. And I'm not sure if I would understand "Kontext".
>> I tend to leave it untranslated.
>
> I don't think "Bereich" is a bad choice. As "hunk"
Am 22.05.2013 17:16, schrieb Ralf Thielow:
hunk = Bereich
IMHO "Kontext" is better if you use a German word. Technically the context is
something else, but in a German text IMHO it fits nicer when explaining to the
user where he/she can select the n-th hunk.
Not sure if Ge
2013/5/20 Christian Stimming :
> Thanks for the update. I would like to add some comments on this G+E glossary
> and I hope you are interested in reading those, even though it is known that I
> prefer a "pure Ger" translation. However, as I wrote in my other message I
> agree that for the command l
2013/5/20 Holger Hellmuth :
> Am 19.05.2013 18:56, schrieb Ralf Thielow:
>
>> 2013/5/16 Holger Hellmuth (IKS) :
>>>
>>>
>> [...]
+reset = neu setzen (maybe "umsetzen"?)
>>>
>>>
>>>
>>> "zurücksetzen"
>>>
>>
>> "reset" can be used with every existing commit. "zurücksetzen"
>> would imp
Thanks for the update. I would like to add some comments on this G+E glossary
and I hope you are interested in reading those, even though it is known that I
prefer a "pure Ger" translation. However, as I wrote in my other message I
agree that for the command line tool the criteria for choosing t
Am 19.05.2013 18:56, schrieb Ralf Thielow:
2013/5/16 Holger Hellmuth (IKS) :
[...]
+reset = neu setzen (maybe "umsetzen"?)
"zurücksetzen"
"reset" can be used with every existing commit. "zurücksetzen"
would imply that it have to be a recent commit, no?
It implies that it sets to s
2013/5/16 Holger Hellmuth (IKS) :
>
[...]
>> +reset = neu setzen (maybe "umsetzen"?)
>
>
> "zurücksetzen"
>
"reset" can be used with every existing commit. "zurücksetzen"
would imply that it have to be a recent commit, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
Hi,
here's an updated version of the glossary. Comments are appreciated.
Basic repository objects:
blob = Blob
tree = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt
submodule = Submodul
pack(noun) = Pack-Datei
pack(verb) = packen (ggf. Pack-Date
}
> } So that leaves us at a point where "the" libre Git book (and also the
> } one that happens to be hosted on git-scm.com, the official site) does
> } not match the terminology used by German git.
> }
> } Like, at all. They're not even remotely near each other.
>
2013/5/16 Holger Hellmuth (IKS) :
>
>> +bare repository= bloßes Repository
>
>
> Since "bloßes Rep." does not convey any sensible meaning to a german reader
> (at least it doesn't to me) it might as well be "bare". Also bare is used as
> parameter to commands
>
>
>> +remote tracking
Dear translators,
Here's the main point in this discussion: The translation is not for us! The
translation is for those who don't speak much English and who don't know the
English git terminology very well. By definition, this target audience is not
present here on this mail
a
} translation of pro-git (which is also quite mature at this point, having
} apparently begun in 2009), and as you probably guessed by now, it's G+E.
}
} So that leaves us at a point where "the" libre Git book (and also the
} one that happens to be hosted on git-scm.com, the offi
+bare repository= bloßes Repository
Since "bloßes Rep." does not convey any sensible meaning to a german
reader (at least it doesn't to me) it might as well be "bare". Also bare
is used as parameter to commands
+remote tracking branch = externer Übernahmezweig
Anyone use
Hi,
I think the discussion might work better via ML than GitHub.
This is the full glossary of git's de.po as it would look
like with (hopefully) all the changes included that have been
discussed here. Still without any reasoning for decisions
(except HEAD).
Thanks for reading.
+Basic repository
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:
>>>
>>> I actually had the '-' in there too until I tried to look up "Zip-Datei"
>>> in the Duden. While I don't get the leading '.' (I cannot remember having
>>> seen that anywhere, AFAIK the file extensions are always used without the
>
Am 15.05.2013 15:14, schrieb Jan Engelhardt:
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
While it's spoken Packdatei, the way to actually write it is
.pack-Datei or ".pack"-Datei.
I actually had the '-' in there too until I tried to look up "Zip-Datei"
in the Duden. While I don't get
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
>>
>> While it's spoken Packdatei, the way to actually write it is
>> .pack-Datei or ".pack"-Datei.
>
>I actually had the '-' in there too until I tried to look up "Zip-Datei"
>in the Duden. While I don't get the leading '.' (I cannot remember hav
Am 15.05.2013 13:56, schrieb Jan Engelhardt:
> On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>> but I believe "Packdatei" would be a much better translation (especially as
>> the translation of "pack(verb)" is "packen"). I find it natural that a file
>> with the extension ".pack" is named Pack
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>
>Hmm, I rather tend towards using "Repository" instead of "Archiv" too, as
>"Archiv" can mean anything from a tar-file to a git repository
It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has no
Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):
> Am 14.05.2013 19:51, schrieb Ralf Thielow:
>> - repository = Projektarchiv
>> - bare repository = bloßes Projektarchiv
>> + repository = Projektarchiv, (or just Repository?)
>> + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repo
Am 14.05.2013 19:51, schrieb Ralf Thielow:
- repository = Projektarchiv
- bare repository = bloßes Projektarchiv
+ repository = Projektarchiv, (or just Repository?)
+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)
I would vote for Repository or if it needs to be trans
Hi all,
I tried to merge these different glossaries together (based on git de.po)
as a new wiki page [1]. You can see the diff against the current git de.po
glossary at [2]. I've also created a branch in my repository which only contains
the wiki page as a text file. This allows comments on each l
On Monday 2013-05-13 20:57, Ralph Haußmann wrote:
>
>There is a glossary for the pro-git book (see [2]) but it is not up-to-date
>and it is also mixed. Therefor I would like to avoid using this glossary.
>I like the idea of a shared wiki (git de.po and pro-git).
>I suggest a single page as over
Hi,
My vote is G+E, too.
lb1a, Florian Breisch and I are working on the german translation of the
pro-git book (hosted on git-scm.com). We use the repository [1] to share
our work. If someone wants to help us, JOIN US!
The current translation of pro-git is mixed, Ger and G+E. For example,
th
Am 13.05.2013 15:57, schrieb Jan Engelhardt:
> On Monday 2013-05-13 14:54, Thomas Rast wrote:
>> My vote is G+E.
>
> Essentially, so is mine. ...
Same here. I frequently get asked to switch Git back to English when the
"LANG=C" gets lost, because my coworkers and myself - almost all of which
are
es us at a point where "the" libre Git book (and also the
> one that happens to be hosted on git-scm.com, the official site) does
> not match the terminology used by German git.
>
> Like, at all. They're not even remotely near each other.
>
> Therefore, a total new
On Monday 2013-05-13 14:54, Thomas Rast wrote:
>As I am sure you are all aware, there are two main religions as to how
>one can translate technical material into German: leave the technical
>terms mostly in English, or translate them to an appropriate
>corresponding word. I'll denote them G+E and
rote a
translation of pro-git (which is also quite mature at this point, having
apparently begun in 2009), and as you probably guessed by now, it's G+E.
So that leaves us at a point where "the" libre Git book (and also the
one that happens to be hosted on git-scm.com, the official s
> So what's the converse of "fetch" (to rename git-ssh-push to)?
> Maybe "ship"?
The opposite of "fetch" is "throw" or "toss".
(Just avoid tossing cookies or off.)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
On Fri, 5 Aug 2005, [EMAIL PROTECTED] wrote:
> On Fri, 5 Aug 2005, Linus Torvalds wrote:
>
> > On Fri, 5 Aug 2005, Johannes Schindelin wrote:
> >
> > > - The files under $GIT_DIR/refs record object names, and are
> > > called "refs". What is under refs/heads/ are called "heads",
> >
Hi,
wow! What a long mail! But I probably deserved it, quoting that lengthy
mail from Junio...
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Johannes Schindelin wrote:
> >
> > Tutorial says "cache" aka "index". Though technically, a cache
> > is the index file _plus_ the rela
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Johannes Schindelin wrote:
>
> > - The files under $GIT_DIR/refs record object names, and are
> > called "refs". What is under refs/heads/ are called "heads",
> > refs/tags/ "tags". Typically, they are either object names
On Fri, 5 Aug 2005, Johannes Schindelin wrote:
>
> Tutorial says "cache" aka "index". Though technically, a cache
> is the index file _plus_ the related objects in the object database.
> git-update-cache.txt even makes the difference between the "index"
> and the "directory cache".
I think we s
Hi,
I am finally finished with my preliminary survey: I took what you sent as
a strawman, and inserted what I found (I tried to say only something about
ambiguous naming):
- The unit of storage in GIT is called "object"; no other word
is used and the word "object" is used only for this pu
Hi,
I tried to avoid the work. But I'll do it.
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Maybe we should decide on a common terminology before kicking out 1.0, and
> look through all files in Documentation/ to have a consistent vocabulary.
> And poor me does not get confused no more.
Glad to see you started the discuss
Hi,
the other day I got confused by the terminology. Maybe I'm not the only
one:
The GIT equivalent of a CVS branch is sometimes called a branch
(git-new-branch), sometimes a tree (git-switch-tree), and sometimes a
head (which seems counterintuitive to CVS people: they only have one
HEAD;
51 matches
Mail list logo