On 8/17/05, Dave Jones [EMAIL PROTECTED] wrote:
In my case, at least the most recent of those cvs tag operations
was just a 'cvs tag x86info-1_14'. Nothing fancy. I'm fairly sure
there was nothing fancy about the earlier instance either.
So sure in fact, I had to look up that -F flag in the
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
translate that character to a '-'. This should work well, despite the
fact that a division and a difference are completely different :-)
Signed-off-by:
Paul Mackerras [EMAIL PROTECTED] writes:
My reasoning is that it is the local short-range connections which are
interesting and informative. The long-range connections aren't really
visually informative; if you want to know about the long-range
connections, the parent and child lists in the
Johannes Schindelin [EMAIL PROTECTED] writes:
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
translate that character to a '-'. This should work well, despite the
fact that a division and a difference
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin [EMAIL PROTECTED] writes:
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
translate that character to a '-'. This should work
Johannes Schindelin [EMAIL PROTECTED] writes:
That may be true, but CVS branches being named H.ANdnsel/Gretel do not
logically denote hierarchies. I never ever saw hierarchical CVS branch
names with a / separator. I saw some with a . separator.
My feeling is that it would be wrong to map
Good catch. Thanks.
-
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
David Kågedal [EMAIL PROTECTED] writes:
The git-cvsimport-script had a copule of small bugs that prevented me
from importing a big CVS repository.
The first was that it didn't handle removed files with a multi-digit
primary revision number.
I noticed that this patch was accepted, which is
On Wed, August 17, 2005 2:58 am, Junio C Hamano said:
Paul Mackerras [EMAIL PROTECTED] writes:
My reasoning is that it is the local short-range connections which are
interesting and informative. The long-range connections aren't really
visually informative; if you want to know about the
Daniel Barkalow wrote:
2) Practical: The round trip git-format-patch + git-applymbox is the logical
and
natural way to reach this goal or, also in this case, I intend to stretch
some tools,
designed for one thing, for something else?
I'd guess that git-diff-tree + git-apply (without the rest
On 8/17/05, Marco Costalba [EMAIL PROTECTED] wrote:
Of course I can feed proper subject and description to git-commit but I would
like
to find something less intrusive
I don't know if it helps, but I think that StGIT is what you are
looking for, not only because you have more tools to deal
Apparently, my mail was encoded as QP, which is not very popular
around here. But it seems that the diff part was decoded properly
before applying. Was that done manually?
Yes, the patch had some context conflicts with some other patch
so the patch application was done by hand, and I did a
Junio C Hamano writes:
The new output looks a lot less cluttering and I like it very
much, but it is confusing to me on one count. I clicked one
arrowhead pointing downward, expecting that the pane would jump
scroll to show the counterpart arrowhead, and was dissapointed
OK, you're the
Junio C Hamano [EMAIL PROTECTED] writes:
Yes, the patch had some context conflicts with some other patch
so the patch application was done by hand, and I did a quick and
dirty cut paste of the commit message from cat mbox output.
I will probably drop future patches encoded in QP.
This was
Junio C Hamano [EMAIL PROTECTED] writes:
Apparently, my mail was encoded as QP, which is not very popular
around here. But it seems that the diff part was decoded properly
before applying. Was that done manually?
Yes, the patch had some context conflicts with some other patch
so the patch
Junio C Hamano [EMAIL PROTECTED] writes:
Junio C Hamano [EMAIL PROTECTED] writes:
Yes, the patch had some context conflicts with some other patch
so the patch application was done by hand, and I did a quick and
dirty cut paste of the commit message from cat mbox output.
I will probably
Avoid that git-format-patch writes out patch series
information on stderr when there are no errors
Signed-off-by: Marco Costalba [EMAIL PROTECTED]
---
git-format-patch-script |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
47238497f48d19a0bf44eb9b23875bbb8e8a12aa
diff --git
Hi, Paul Mackerras wrote:
http://ozlabs.org/~paulus/gitk/gitk.hs
Unfortunately, this fails on my git-plus-assorted-crap archive:
can't read mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283): no such
element in array
can't read mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283): no
Hi,
long, long time. Here´s my first stab at the glossary, attached the
alphabetically sorted, asciidoc marked up txt file (Comments?
Suggestions? Pizzas?):
object::
The unit of storage in GIT. It is uniquely identified by
the SHA1 of its contents. Consequently, an object can
On Tue, 16 Aug 2005, Junio C Hamano wrote:
This is a companion patch to the previous format-patch fix.
With -k, format-patch can be told not to remove the [PATCH] in
the original commit, nor to add the [PATCH] on its own.
I think this might be the point in time to just make the [PATCH]
Hi, Sean wrote:
The line flowing from this commit extends ~200 more commits downward
before it is finally terminated with an arrowhead. It would be nice if
this line could be made shorter, such that the arrowhead was drawn much
closer to commit in question.
Good point. The arrowheads tend
I wanted to get a clean 2.6.12-rc6-git8 tree, so I looked up the commit
id (3edea4833a1efcd43e1dff082bc8001fdfe74b34) at
http://kernel.org/pub/linux/kernel/v2.6/snapshots/, updated my .git
repository with
rsync -a --delete --verbose --stats --progress \
Marco Costalba [EMAIL PROTECTED] wrote:
Suppose a possible scenario involves using a couple of git archives, one
for releases and stable code, say MAIN, and one for experimental stuff
or new development, say HEAD.
Suppose there is stuff in HEAD you don't want merged in MAIN, more,
you
Hi,
the round trip
1) git-format-patch --mbox --keep-subject
2) git-applymbox -k
is not perfect for revisions where there is only the subject.
An example is c35a7b8d806317dc1762e36561cbd31c2530dd9c in git archive
Original text is:
Skip merges in format-patch.
After round trip:
Hi, Martin Langhoff wrote:
this one is the
most likely one to be from a bug in cvsps or the cvsimport logic.
That's not a bug in the import logic, just a failure of the CVS-merging
person to be consistent. (Which is hardly news. :-/ )
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de |
Catalin Marinas wrote:
Once you want a subset of these patches merged into MAIN, just pop
everything from the stack and only push those you want merged, in the
order you want (if there are some dependencies, the push will fail and
you can correct them or the order). When you are happy with the
If someone is thus motivated, I have two requests in this area:
1) Fix applymbox such that it understands RFC822-valid Subject lines
which wrap across multiple text lines.
2) Teach it to understand MIME, and not treat the MIME headers like part
of the message.
-
To unsubscribe from this
Marco Costalba wrote:
This way I found StGIT useful for maintainers as well, not only for
contributors.
Sorry if the answer is silly, but I still don't know well StGIT .
'question' not 'answer'
I don't now if the question is silly, but the typo it is for sure!
Sorry
Marco
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
Hi,
long, long time. Here?s my first stab at the glossary, attached the
alphabetically sorted, asciidoc marked up txt file (Comments?
Suggestions? Pizzas?):
object::
The unit of storage in GIT. It is uniquely identified by
the
Johannes Schindelin [EMAIL PROTECTED] writes:
Hi,
On Wed, 17 Aug 2005, Marco Costalba wrote:
P.S: I say 'revision', and 'git archive' but are very common also
'commit' and 'git repository'. This is just a silly example where a
common dictionary should be useful.
I think 'commit' and
Junio C Hamano [EMAIL PROTECTED] writes:
I do not think we have agreed to limit ourselves to a flat
namespace under refs/heads without subdirectories. Something
like what git-show-branches-script does when $# == 0, perhaps?
I didn't realise this. I'll send a revised patch soon.
--
Kalle
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
Marco Costalba [EMAIL PROTECTED] writes:
So 'revision' is the struct and 'commit object' the pointer ;-)
It would be more like revision is a concept represented (not
referenced) by a commit object.
Actually, I think it is referenced,
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
SHA1::
A 20-byte sequence (or 41-byte file containing the hex
representation and a newline). It is calculated from the
contents of an object by the Secure Hash Algorithm 1.
Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time. So
export the single-path interface too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
cache.h |1 +
setup.c |2 +-
2 files changed, 2
This also makes ./filename acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
update-cache.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ece92eeda777c3141f5692132ccc2ba7e4e801a2
diff --git
Matt Draisey [EMAIL PROTECTED] writes:
Having thus been forced to read the mailing list, I see a slight problem
in .git/objects/info/alternates mechanism. Using the original
ALTERNATE_DB_ENVIRONMENT variable you assert to the git programmes that
you know all the repositories to search for
Johannes Schindelin [EMAIL PROTECTED] writes:
Okay for hash. What is the consensus on object name being more
standard than SHA1?
The tutorial uses the term object name, so does README
(implicitly, by saying All objects are named by their content,
which is approximated by the SHA1 hash of the
On Wed, 2005-08-17 at 10:35 -0700, Marco Costalba wrote:
Sorry if the answer is silly, but I still don't know well StGIT .
It's probably because there is no document really explaining the
concepts. The Quilt documentation would be a good starting point since
StGIT uses the same ideas but
Hi Catalin,
maybe it is time for a quick run through the typical jobs you do with
StGIT, much like what Jeff sent the other day?
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
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
[...]
Okay for hash.
I think we only need at most two names for this, so this is more a matter
of fixing old usage than documenting it.
It's
Paul Mackerras [EMAIL PROTECTED] writes:
OK, you're the second person to ask for that, so I'll see what I can
do about it. I can think of 3 possible behaviors when you click on
the arrowhead:
1. scroll to bring the other arrowhead on-screen and briefly make it
larger or something
Wolfgang Denk [EMAIL PROTECTED] writes:
The display in gitk --all gets changed a bit (before the branch was
the leftmost line, now it's the rightmost one), but it's still a
dangling head, and the selected merge point (commit 24ee89) is
still displayed with just one parent
Junio C Hamano writes:
My Tcl/Tk is really rusty, and I do not like this patch, but
here is my stab at teaching the code that reads commit objects
how to use grafts as well.
I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now. I also committed the changes
We have a small team of 3, and our main activity is to run local
branches of upstream projects, plus some local development. In that
context, I am designing our cogito/git usage strategy, and I'm
interested in comments.
My intention is to use cogito as much as possible, and insulate our
team from
On Thu, 18 Aug 2005, Paul Mackerras wrote:
I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now. I also committed the changes to send lines into
hyperspace.
Paul, I hate to tell you about yet another flag to git-rev-list, but did
you realize that in
45 matches
Mail list logo
