Re: FUNKY tags.
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 man page to find out what it did. Ok - that reduces the suspects to - a tag applied to only one part of the tree - a tag that took longer to apply than fuzztime (large tree, slow cvs connection?) let me know, and if I find time I may look at the repo. martin - 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
[PATCH] Also handle CVS branches with a '/' in their name
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: Johannes Schindelin [EMAIL PROTECTED]
---
git-cvsimport-script |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
787879e1e16d6cece75dc4744358ba0073e908cc
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -621,6 +621,7 @@ while(CVS) {
$state = 4;
} elsif($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
+ s/\//-/g;
$branch = $_;
$state = 5;
} elsif($state == 5 and s/^Ancestor branch:\s+//) {
-
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
Re: gitk with hyperspace support
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 details pane are much more useful. Correct. 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 that it did not happen. I could click the Parent link at that point, but then the upward arrow was above and outside the visible portion of that pane, which broke visual continuity and I lost track at that point. I think my being color challenged exacerbated the resulting confusion; otherwise I could have probably found the line with the same color as the color of the downarrow I clicked. http://ozlabs.org/~paulus/gitk/gitk.hs I first thought you rewrote it in Haskell ;-). - 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
Re: [PATCH] Also handle CVS branches with a '/' in their name
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 are completely different :-) My feeling is that there should be nothing to prevent you from having a non-flat namespace in .git/refs/heads; i.e. we should allow .git/refs/heads/foo/bar. Some of the existing tools may be forgetting to call either mkdir -p $(dirname $ref) if they are written in shell, or safe_create_leading_directories(ref) in C, but I consider that is a bug. - 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
Re: [PATCH] Also handle CVS branches with a '/' in their name
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 well, despite the fact that a division and a difference are completely different :-) My feeling is that there should be nothing to prevent you from having a non-flat namespace in .git/refs/heads; i.e. we should allow .git/refs/heads/foo/bar. That may be true, but CVS branches being named Hänsel/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 CVS branch names to a hierarchy. Ciao, Dscho
Re: [PATCH] Also handle CVS branches with a '/' in their name
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 CVS branch names to a hierarchy. Although I've used / in CVS branch names to denote hierarchy, I now agree with you for a different reason. A CVS repository can have branches Hnsel and Hnsel/Gretel at the same time, which we cannot express it with '/'. However, this may make CVS tags Hnsel/Gretel and Hnsel-Gretel clash, so maybe the name mangling should be made somehow configurable? - 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
Re: [PATCH] When copying or renaming, keep the mode, please
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
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
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 great. But there is a problem with the character encoding in the commit message. The commit in question is b0921331030d52febf52839753eee1b2b9ca1f24 The author field is written as iso-8859-1?Q?David_K=E5gedal [EMAIL PROTECTED], which is taken from the From: line in my email. This should be decoded by the patch import script before generating the commit message. But the trickier question is what encoding to use in the commit message. This is the signed-off line in my mail: Signed-off-by: David Kågedal [EMAIL PROTECTED] This is what appears in the commit: Signed-off-by: David K?5gedal [EMAIL PROTECTED] Using ISO-8859-15 or UTF-8 would probably have made more sense here. 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? Since my name contains a character that is not part of ASCII, it isn't really an option to send the mails encoded as ASCII. I could probably convince my mailer (Gnus) to send it as 8bit or binary, but that is a pretty limited solution. An it isn't even legal to use anything but ASCII in the mail header. -- David Kågedal - 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
Re: gitk with hyperspace support
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 long-range connections, the parent and child lists in the details pane are much more useful. Correct. 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 that it did not happen. I could click the Parent link at that point, but then the upward arrow was above and outside the visible portion of that pane, which broke visual continuity and I lost track at that point. I think my being color challenged exacerbated the resulting confusion; otherwise I could have probably found the line with the same color as the color of the downarrow I clicked. This change looks really good in gitk and clicking on an arrowhead to hop to the corresponding arrowhead would sure be great too. There's may be a way to further reduce the line clutter too; once a line is terminated with an arrowhead, it could often be trimmed back much further. For instance looking at Linus' tree: 03938c3f1062b0f279a0ef937a471d4db83702ed powernow-k8 requires that a data structure for 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. Cheers, Sean - 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
Re: [RFC] Patches exchange is bad?
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 of the scripting) would be more effective when you're not doing anything with the intermediate files, since it saves doing a bunch of formatting and parsing. It would be surely better, but I need to import also the original subject and description. I can use git-diff-tree --pretty -p for the patch creation, but this format is not compatible with git-apply* scripts, and the git command git-apply does not import subject + description info. Of course I can feed proper subject and description to git-commit but I would like to find something less intrusive as possible, ie. one command for patch export, one command for patch import. Thanks Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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
Re: [RFC] Patches exchange is bad?
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 with patches, but also because patches that are in the 'stack' are actually really malleable. You can edit and reedit the patch w its commit msg and all, commit it to the stack, and reedit it again later. It only becomes immutable when you commit to the underlying git repo. cheers, martin - 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
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
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 quick and dirty cut paste of the commit message from cat mbox output. I will probably drop future patches encoded in QP. - 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
Re: gitk with hyperspace support
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 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 similar to draw attention to it 2. scroll to bring the other arrowhead on-screen and warp the pointer to it 3. select the next commit in the indicated direction which is a child or parent that the line connects (scroll to make it visible, highlight it, show its diff). Which do you think would be best? http://ozlabs.org/~paulus/gitk/gitk.hs I first thought you rewrote it in Haskell ;-). Hmmm, maybe it's apache on ozlabs.org that is under that misapprehension? Thanks, Paul. - 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
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
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 totally inappropriate; sorry, but I was in a bad mood. A more serious response. - I personally consider commit message encoding a per project issue (so is blob contents encoding). If for example a project is Japanese only, MS-DOS^WWindows programming project, I do not think it is unreasonable if all the commit messages and source files are encoded in Shift-JIS. More Unixy projects over there might use EUC-JP in source files and maybe ISO-2022 in the log messages (because the latter is the standard way to exchange e-mails there). As long as project participants agree to use the same encodings, things should work just fine within a project. - However, weird people are known to merge projects that started out as totally separate into one. It would be a disaster for the commit log viewer when this happens. For this reason, some people recommend using a common deniminator encoding, namely UTF-8, for commit logs from day one, even if you do not envision such a merge may happen in the future. This recommendation also goes to author and committer identification (but not blob contents). But this is just an recommendation, and it is still up to the individual project what encoding to use in the log messages, and the low-level GIT should not dictate nor interfere; git-commit-tree and git-cat-file commit are 8-bit clean. - The e-mail patch acceptance machinery found in tools/ directory is tuned for the established patch exchange practice used in the linux-kernel mailing list. No MIME, no QP, no guarantee to pass things outside ASCII. - Eventually, tools/mailinfo.c should be taught about MIME to do at least: - detect whitespace corrupted patch via sending MUA using flowed-text and reject it; - detect multipart PGP signed message, discard the attached signature which is often useless, and unwrap the payload; - decode QP and B encodings as necessary, and after splitting the message to the info, msg and patch part, transliterate the info and msg part from original encoding to UTF-8 (when '--utf8' flag is given, perhaps). One of the requirement there is that it still needs to be _fast_. Linus needs to be able to make 5 commits per second out of his mailbox. So that is the technical part of the response. There is one Project policy part of the response: I would endorse the application of that UTF-8 recommendation to the git project itself, at least in principle. But that in practice would happen only after the above mailinfo update takes place. Until then, it is very likely that I will occasionally fail to spot and to hand-correct people's name left undecoded the way the patch acceptance machinery passed through in the log message. Please live with it (or send such patches to mailinfo ;-). - 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
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
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 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. Ok, but do you have an answer to my real question? What is the character encoding for commit objects in your git repository? It is obviously one that is compatible with ASCII, which probably leaves you with the alternatives ASCII, Latin1, and UTF-8. And plain ASCII obviously doesn't work very well for me. -- David Kågedal - 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
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
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 drop future patches encoded in QP. This was totally inappropriate; sorry, but I was in a bad mood. A more serious response. - I personally consider commit message encoding a per project issue (so is blob contents encoding). Agreed. And your response is probably good enough for now. I also think that having UTF-8 as the standard convention is the way to go. -- David Kågedal - 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
[PATCH] Let git-format-patch-script write on stdout
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 a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -146,7 +146,7 @@ do
file=`printf '%04d-%stxt' $i $title`
i=`expr $i - 1`
-echo 2 * $file
+echo 1 * $file
{
mailScript='
/./d
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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
Re: gitk with hyperspace support
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 such
element in array
while executing
if {$mainlinearrow($id) ne none} {
set mainline($id) [trimdiagstart $mainline($id)]
}
(procedure drawcommitline line 44)
invoked from within
drawcommitline $dlevel
(procedure drawmore line 65)
invoked from within
drawmore 1
(procedure drawcommit line 33)
invoked from within
drawcommit $id
(procedure getcommitlines line 50)
invoked from within
getcommitlines file23
Another problem: when I click on a line, I get the parent and *all* its
children, not just the child(ren) on the other end of the segment I was
clicking on.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
There are some micro-organisms that exhibit characteristics of both plants
and animals. When exposed to light they undergo photosynthesis; and when
the lights go out, they turn into animals. But then again, don't we all?
-
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
First stab at glossary
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 not be changed. 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. object database:: Stores a set of objects, and an individial object is identified by its SHA1 (its ref). The objects are either stored as single files, or live inside of packs. object name:: Synonym for SHA1. blob object:: Untyped object, i.e. the contents of a file. tree object:: An object containing a list of blob and/or tree objects. (A tree usually corresponds to a directory without subdirectories). tree:: Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree). cache:: A collection of files whose contents are stored as objects. The cache is a stored version of your working tree. Well, can also contain a second, and even a third version of a working tree, which are used when merging. cache entry:: The information regarding a particular file, stored in the index. A cache entry can be unmerged, if a merge was started, but not yet finished (i.e. if the cache contains multiple versions of that file). index:: Contains information about the cache contents, in particular timestamps and mode flags (stat information) for the files stored in the cache. An unmerged index is an index which contains unmerged cache entries. working tree:: The set of files and directories currently being worked on. Think ls -laR directory:: The list you get with ls :-) checkout:: The action of updating the working tree to a revision which was stored in the object database. revision:: A particular state of files and directories which was stored in the object database. It is referenced by a commit object. commit:: The action of storing the current state of the cache in the object database. The result is a revision. commit object:: An object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision. changeset:: BitKeeper/cvsps speak for commit. Since git does not store changes, but states, it really does not make sense to use the term changesets with git. ent:: Favorite synonym to tree-ish by some total geeks. clean:: A working tree is clean, if it corresponds to the revision referenced by the current head. dirty:: A working tree is said to be dirty if it contains modifications which have not been committed to the current branch. head:: The top of a branch. It contains a ref to the corresponding commit object. branch:: A non-cyclical graph of revisions, i.e. the complete history of a particular revision, which does not (yet) have children, which is called the branch head. The branch heads are stored in $GIT_DIR/refs/heads/. ref:: A 40-byte hex representation of a SHA1 pointing to a particular object. These are stored in $GIT_DIR/refs/. head ref:: A ref pointing to a head. Often, this is abbreviated to head. Head refs are stored in $GIT_DIR/refs/heads/. tree-ish:: A ref pointing to either a commit object, a tree object, or a tag object pointing to a commit or tree object. tag object:: An object containing a ref pointing to another object. It can contain a (PGP) signature, in which case it is called signed tag object. tag:: A ref pointing to a tag or commit object. In contrast to a head, a tag is not changed by a commit. Tags (not tag objects) are stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with a Lisp tag (which is called object type in git's context). merge:: To merge branches means to try to accumulate the changes since a common ancestor and apply them to the first branch. An automatic merge uses heuristics to accomplish that. Evidently, an automatic merge can fail. resolve:: The action of fixing up manually what a failed automatic merge left behind. repository:: A collection of refs together with an object database containing all objects, which are reachable from the refs. A repository can share an object database
Re: [PATCH] Teach applymbox to keep the Subject: line.
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] prefix go away. It made much more sense with BK than it does with git: since git keeps track of author and committer separately, you can always see when the committer wasn't the author of the change, which is what the [PATCH] thing was all about. In other words, at least for the kernel, [PATCH] was a marker that said the author didn't commit this directly. Git already has that information explicitly in the git data. (Also, with proper Signed-off-by: lines it's also always clear that there were other people involved, and that the author of the patch is different from the person who applied it). So I would personally not mind if we just made the [PATCH] prefix go away entirely, or perhaps had a separate flag to git-applymbox that told it to prepend a specific prefix to the Subject: line (which might not be [PATCH] at all) defaulting to no prefix. Linus PS. Another historical reason for marking patches explicitly was that people were worried that introducing BK would somehow make the old patch-based submissions be second-class citizens. It was easy to make statistics and show that at least half the real changes (as opposed to merges) were still patch-based. So again, the PATCH marker had some historical relevance, but I don't think it matters any more. - 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
Re: gitk with hyperspace support
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 to get lost otherwise; in my tree, the
problem is even worse since the downward-pointing arrow (drawn in grey) is
directly below a horizontal line connecting two unrelated changes -- which
is *also* grey. That makes the actual arrowhead perceptually invisible.
If the arrow appears directly below a node, you don't get that problem.
Another point I just noticed: The arrows should be directly below
each other, if at all possible; i.e. the one pointing up should be in the
same column as the corresponding arrow pointing down.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Money is the root of all evil, and man needs roots.
-
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
rc6-git8 Makefile from cg-export and bz2 patch don't agree
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 \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ .git/ then did cg-export /tmp/xyz commit-id Strangely, the Makefile doesn't match what I would get by applying patch-2.6.13-rc6-git8.bz2. In the exported Makefile, EXTRAVERSION =-rc6 whereas from the patch, Makefile (line 151 of the diff) has EXTRAVERSION = -rc6-git8 Was this a case of hand-editing the diff or did I not use the cg/git commands correctly? -Sanjoy `A society of sheep must in time beget a government of wolves.' - Bertrand de Jouvenal - 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
Re: [RFC] Patches exchange is bad?
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 need to update MAIN with only a subset of patches in HEAD, peraphs
in different order. Or simply, you are not interested to see the history
of the HEAD tree when looking MAIN. All this points could keep you
from merging.
As others already recommended StGIT, I will just add a simple usage
scenario (I do this with my StGIT repository).
The MAIN/stable repository (or branch) is only managed with GIT, not
StGIT. The HEAD one is managed with StGIT (only, you can use 'stg
clone'). You can create patches, modify them etc. (I updated the
README in the latest snapshot and it contains some kind of tutorial).
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
patches pushed on the stack, just do a 'git pull HEAD' in the MAIN
repository. After this, doing a 'stg pull MAIN' in the HEAD one will
mark the patches already integrated into MAIN as empty and you can
safely remove them ('stg clean' does this automatically).
This way I found StGIT useful for maintainers as well, not only for
contributors.
--
Catalin
-
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
git-format-patch + git-applymbox small issue
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: Skip merges in format-patch. git-format-patch-script |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) c35a7b8d806317dc1762e36561cbd31c2530dd9c I know I'm a bit annoying ;-) Marco 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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
Re: [PATCH] Add merge detection to git-cvsimport
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 | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Reason:
Bad, toxic entity, that foolish people use when they ought to use
their inner voice, or angels, or intuition, or a gut feeling, or
their hearts, or the I Ching.
-- Fashionable Dictionary (www.butterfliesandwheels.com)
-
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
Re: [RFC] Patches exchange is bad?
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
patches pushed on the stack, just do a 'git pull HEAD' in the MAIN
repository. After this, doing a 'stg pull MAIN' in the HEAD one will
mark the patches already integrated into MAIN as empty and you can
safely remove them ('stg clean' does this automatically).
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 .
What you describe it's an asymmetrical or one way scenario, new code
goes always from HEAD to MAIN. But how is the workflow if:
1) There is more then one contributor feeding MAIN and you need to update
the StGIT patch stack from MAIN.
2) You made something terribly wrong with HEAD (I don't know what can be
'terribly wrong') and you need to recreate a clean base from MAIN.
In this cases, if I understand correctly, you need to clone a new StGIT archive
from
MAIN and push the interesting stuff from old/broken HEAD.
Or you can always merge back pulling from MAIN as in case of two pure git
archives?
Thanks
Marco
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
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
Re: [PATCH] Teach applymbox to keep the Subject: line.
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 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
Re: [RFC] Patches exchange is bad?
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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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
Re: First stab at glossary
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 SHA1 of its contents. Consequently, an object can not be changed. 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. It's also often 40-character string (with whatever termination) in places like commit objects, tag objects, command-line arguments, listings, and so forth. object database:: Stores a set of objects, and an individial object is identified by its SHA1 (its ref). The objects are either stored as single files, or live inside of packs. object name:: Synonym for SHA1. Have we killed the use of the third term hash for this? I'd say that object name is the standard term, and SHA1 is a nickname, if only because object name is more descriptive of the particular use of the term. blob object:: Untyped object, i.e. the contents of a file. This i.e. should be e.g., since symlink targets are also stored as blobs, and any other bulk data stored by itself would be. (IIRC, Junio has a tagged blob to hold his public key, for example) tree object:: An object containing a list of blob and/or tree objects. (A tree usually corresponds to a directory without subdirectories). tree:: Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree). cache:: A collection of files whose contents are stored as objects. The cache is a stored version of your working tree. Well, can also contain a second, and even a third version of a working tree, which are used when merging. cache entry:: The information regarding a particular file, stored in the index. A cache entry can be unmerged, if a merge was started, but not yet finished (i.e. if the cache contains multiple versions of that file). index:: Contains information about the cache contents, in particular timestamps and mode flags (stat information) for the files stored in the cache. An unmerged index is an index which contains unmerged cache entries. I think we might want to entirely kill the cache term, and talk only about the index and index entries. Of course, a bunch of the code will have to be renamed to make this completely successful, but we could change the glossary and documentation, and mention cache and cache entry as old names for index and index entry respectively. working tree:: The set of files and directories currently being worked on. Think ls -laR This is where the data is actually in the filesystem, and you can edit and compile it (as opposed to a tree object or the index, which semantically have the same contents, but aren't presented in the filesystem that way). directory:: The list you get with ls :-) checkout:: The action of updating the working tree to a revision which was stored in the object database. Move after revision? revision:: A particular state of files and directories which was stored in the object database. It is referenced by a commit object. commit:: The action of storing the current state of the cache in the object database. The result is a revision. commit object:: An object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision. Move parent around here. changeset:: BitKeeper/cvsps speak for commit. Since git does not store changes, but states, it really does not make sense to use the term changesets with git. ent:: Favorite synonym to tree-ish by some total geeks. Move after tree-ish. head:: The top of a branch. It contains a ref to the corresponding commit object. branch:: A non-cyclical graph of revisions, i.e. the complete history of a particular revision, which does not (yet) have children, which is called the branch head. The branch heads are stored in $GIT_DIR/refs/heads/. A branch head might have children, if they're in another branch. (E.g., I pull mainline, make a new branch based on it, and commit a change; the head of mainline is still a branch head, even though it's the parent of my new commit, because my new commit isn't in mainline.) ref:: A 40-byte hex representation of a SHA1 pointing to a particular object. These are stored in $GIT_DIR/refs/. head ref:: A ref pointing to a head. Often, this
Re: git-format-patch + git-applymbox small issue
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 'repository' are more commonly seen here. How about the glossary, which I posted a few hours ago? Which is very good. Thanks. Mind if I put it under Documentation/ in its current shape? - 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
Re: [PATCH] Change git-branch to list branches
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 Valo - 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
Re: git-format-patch + git-applymbox small issue
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, because the commit object contains a little metadata, and then only refs (pointers). Agreed. I personally think the word archive on this list came from people who have some degree of tla background. CVS and SVN people would have said repository. I'll add it anyway. 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
Re: First stab at glossary
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. It's also often 40-character string (with whatever termination) in places like commit objects, tag objects, command-line arguments, listings, and so forth. Okay. object name:: Synonym for SHA1. Have we killed the use of the third term hash for this? I'd say that object name is the standard term, and SHA1 is a nickname, if only because object name is more descriptive of the particular use of the term. Okay for hash. What is the consensus on object name being more standard than SHA1? blob object:: Untyped object, i.e. the contents of a file. This i.e. should be e.g., since symlink targets are also stored as blobs, and any other bulk data stored by itself would be. (IIRC, Junio has a tagged blob to hold his public key, for example) Agree. I think we might want to entirely kill the cache term, and talk only about the index and index entries. Of course, a bunch of the code will have to be renamed to make this completely successful, but we could change the glossary and documentation, and mention cache and cache entry as old names for index and index entry respectively. For me, index is just the file named index (holding stat data and a ref for each cache entry). That is why I say an index contains cache entries, not index entries (wee, that sounds wrong :-). working tree:: The set of files and directories currently being worked on. Think ls -laR This is where the data is actually in the filesystem, and you can edit and compile it (as opposed to a tree object or the index, which semantically have the same contents, but aren't presented in the filesystem that way). Maybe I was too cautious. Linus very new idea was to think of the lowest level of an SCM as a file system. But I did not want to mention that. Thinking of it again, maybe I should. checkout:: Move after revision? Ultimately, the glossary terms will be sorted alphabetically. If you look at the file attached to my original mail, this is already sorted and marked up using asciidoc. However, I wanted you and the list to understand how I grouped terms. The asciidoc'ed file is generated by a perl script. Move parent around here. See above. Move after tree-ish. Ditto. branch:: A non-cyclical graph of revisions, i.e. the complete history of a particular revision, which does not (yet) have children, which is called the branch head. The branch heads are stored in $GIT_DIR/refs/heads/. A branch head might have children, if they're in another branch. (E.g., I pull mainline, make a new branch based on it, and commit a change; the head of mainline is still a branch head, even though it's the parent of my new commit, because my new commit isn't in mainline.) Well noted! I'll just delete that part. tag:: A ref pointing to a tag or commit object. In contrast to a head, a tag is not changed by a commit. Tags (not tag objects) are stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with a Lisp tag (which is called object type in git's context). As above, only the head for the branch being committed to is changed by a commit. A tag, not being the head of a branch, is therefore never changed by a commit. I tried to say that. resolve:: The action of fixing up manually what a failed automatic merge left behind. Resolve is also used for the automatic case (e.g., in git-resolve-script, which goes from having two commits and a message to having a new commit). I'm not sure what the distinction is supposed to be. I did not like that naming anyway. In reality, git-resolve-script does not resolve anything, but it merges two revisions, possibly leaving something to resolve. 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
[PATCH 1/2] Export relative path handling prefix_path() function
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 insertions(+), 1 deletions(-)
c06157a36e49182c34e1e92aa7b329bde5dca3f9
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -142,6 +142,7 @@ extern char *get_graft_file(void);
extern const char **get_pathspec(const char *prefix, char **pathspec);
extern const char *setup_git_directory(void);
+extern char *prefix_path(const char *prefix, int len, char *path);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
@@ -1,6 +1,6 @@
#include cache.h
-static char *prefix_path(const char *prefix, int len, char *path)
+char *prefix_path(const char *prefix, int len, char *path)
{
char *orig = path;
for (;;) {
-
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
[PATCH 2/2] Make git-update-cache take relative pathnames
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 a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -321,6 +321,7 @@ int main(int argc, char **argv)
{
int i, newfd, entries, has_errors = 0;
int allow_options = 1;
+ const char *prefix = setup_git_directory();
newfd = hold_index_file_for_update(cache_file, get_index_file());
if (newfd 0)
@@ -381,6 +382,7 @@ int main(int argc, char **argv)
}
die(unknown option %s, path);
}
+ path = prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
if (!verify_path(path)) {
fprintf(stderr, Ignoring path %s\n, argv[i]);
continue;
-
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
Re: symlinked directories in refs are now unreachable
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 objects. In the .git/objects/info/alternates mechanism you implicitly defer to other repositories, which might also implicitly defer to yet another repository. To ensure an object is truly available you need to compute a transitive closure on all .git/objects/info/alternates --- you can't really rely on .git/objects/info/alternates being transitively closed already. No, git clone -l -s not copying the objects/info/alternates of the repository being cloned was simply a bug; by doing so the transitive closure can be set up initially. Both the environment variable and objects/info/alternates share the same problem if the cloned/borrowed from repository suddenly starts to borrow from another repository, losing objects it used to have from itself. You just shouldn't do it. With objects/info/alternates, you _could_ do the transitive closure at runtime and do not have to worry about this issue (but you now need to worry about cycles), which you cannot do with the environment variable approach. - 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
Re: First stab at glossary
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 object itself). I think it is pretty safe to assume the list agrees with this term. For me, index is just the file named index (holding stat data and a ref for each cache entry). That is why I say an index contains cache entries, not index entries (wee, that sounds wrong :-). I think Linus already commented on using index file and index entries as the canonical terms. It would be a good idea to mention cache as a historical synonym in the documentation, so that we do not have to rename the symbols in the code. Ultimately, the glossary terms will be sorted alphabetically. If you look at the file attached to my original mail, this is already sorted and marked up using asciidoc. However, I wanted you and the list to understand how I grouped terms. The asciidoc'ed file is generated by a perl script. Then we should put the text version under Documentation, along with that script and a Makefile entry to do asciidoc and another to go to html. No rush for the script and Makefile entries, but it would make things easier to manage if we put the text version in the tree soonish. I've pushed out the one from your original First stab message. branch:: A non-cyclical graph of revisions, i.e. the complete history of a particular revision, which does not (yet) have children, which is called the branch head. The branch heads are stored in $GIT_DIR/refs/heads/. I wonder if there is a math term for a non-cyclical graph that has a single greater than anything else in the graph node (but not necessarily a single but possibly more lesser than anything else in the graph nodes)? tag:: A ref pointing to a tag or commit object. In contrast to a head, a tag is not changed by a commit. Tags (not tag objects) are stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with a Lisp tag (which is called object type in git's context). I think this is good already, but maybe mention why you would use a tag in a sentence? Most typically used to mark a particular point in the commit ancestry chain, or something. resolve:: The action of fixing up manually what a failed automatic merge left behind. Resolve is also used for the automatic case (e.g., in git-resolve-script, which goes from having two commits and a message to having a new commit). I'm not sure what the distinction is supposed to be. I did not like that naming anyway. In reality, git-resolve-script does not resolve anything, but it merges two revisions, possibly leaving something to resolve. I am sure this would break people's script, but I am not against renaming git-resolve-script to say git-merge-script. Anyway, thanks for doing this less-fun and not-so-glorious job. - 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
Re: [RFC] Patches exchange is bad?
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 implemented on top if GIT instead of a series of GNU diff files. What you describe it's an asymmetrical or one way scenario, new code goes always from HEAD to MAIN. But how is the workflow if: It is asymmetrical since HEAD uses StGIT and MAIN uses plain GIT but it is a two way data flow: 'git pull HEAD' in MAIN and 'stg pull MAIN' in HEAD. 1) There is more then one contributor feeding MAIN and you need to update the StGIT patch stack from MAIN. The base of the StGIT stack in the HEAD repository (branch) should always be the head of the MAIN repository. You update it via the 'stg pull' command, which takes care of updating the patches so that they are seen as individual commits on top of the base. That's how you would normally do development on Linux using StGIT - clone the mainline kernel, create patches in your StGIT tree and submit them either via e-mail or ask the gatekeeper to pull directly from your tree (assuming that you only push those patches that need to be merged). Doing a 'stg pull' would retrieve the latest changes from the mainline kernel (including the changes made by your patches which were merged upstream). 2) You made something terribly wrong with HEAD (I don't know what can be 'terribly wrong') and you need to recreate a clean base from MAIN. In this cases, if I understand correctly, you need to clone a new StGIT archive from MAIN and push the interesting stuff from old/broken HEAD. This is not clear for me. What do you mean by 'terribly wrong'? Broken HEAD because of a bug in StGIT or GIT? Quite unlikely but in this case the repository would be corrupt. I would recommend periodically doing a 'stg export' to keep the series of patches in GNU diff files. If you refer to a patch which breaks the code, you can simply pop it from the stack and even delete it with 'stg delete'. Popping it removes the changes it makes to HEAD and the corresponding commit won't be seen with 'git log'. You don't need to clone a new repository since StGIT allows you to choose which of your patches (commits) are included in HEAD (via 'stg push' and visible with 'stg applied'). Or you can always merge back pulling from MAIN as in case of two pure git archives? The base of the StGIT stack is identical to MAIN. Doing a 'stg pop -a' makes the HEAD and MAIN identical. Please let me know if this needs further clarification. -- Catalin - 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
Re: [RFC] Patches exchange is bad?
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 http://vger.kernel.org/majordomo-info.html
Re: First stab at glossary
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 short enough to keep it in the glossary _and_ fix the old documentation. [blabla] index [blable] cache [bliblo] Well, it often contains information not present anywhere else (the status of a merge; the set of files being committed, added, or removed), so it isn't really a cache at all. Okay, okay. I stand corrected. Maybe I was too cautious. Linus very new idea was to think of the lowest level of an SCM as a file system. But I did not want to mention that. Thinking of it again, maybe I should. You probably don't need to mention that tree objects and index files can be thought of as filesystems, but you should specify that the working tree really is in the Unix filesystem, in case people have heard of the idea. It should be clear to say 'You can cd there and ls to list your files.', rather than 'Think ls -laR' which makes my think of the output, which is like the output from git-ls-files. How about this: working tree:: The set of files and directories currently being worked on, i.e. you can work in your working tree without using git at all. checkout:: Move after revision? Ultimately, the glossary terms will be sorted alphabetically. If you look at the file attached to my original mail, this is already sorted and marked up using asciidoc. However, I wanted you and the list to understand how I grouped terms. The asciidoc'ed file is generated by a perl script. Ah, okay. Sorry, I attributed these moving suggestions to the large and angry SCM, while those were your comments. Since Junio decided to keep the topic ordered form in his repository, I moved them around according to your mail. resolve:: The action of fixing up manually what a failed automatic merge left behind. Resolve is also used for the automatic case (e.g., in git-resolve-script, which goes from having two commits and a message to having a new commit). I'm not sure what the distinction is supposed to be. I did not like that naming anyway. In reality, git-resolve-script does not resolve anything, but it merges two revisions, possibly leaving something to resolve. Right; I think we should change the name of the script. How many users are there? Probably many call git-pull-script anyway, right? 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
Re: gitk with hyperspace support
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 similar to draw attention to it 2. scroll to bring the other arrowhead on-screen and warp the pointer to it 3. select the next commit in the indicated direction which is a child or parent that the line connects (scroll to make it visible, highlight it, show its diff). Which do you think would be best? Hmph. I think, aside from being color challenged, the primary source of confusion for me was that the lines with arrowheads were too long, and the node and the arrowhead did not fit within the height of the graphical pane, at least with my window configuration. I wonder if not having downward or upward arrows for a long stretch would work better. Lose the vertical line for such hyperspace links, and instead have a horizonal short line with arrowheads to denote that there are also hyperspace lines coming into or out of that node. That way you can save one column for a vertical line, and my preference for clicking on such an arrowhead would be #3 from the above. - 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
Re: [PATCH] Teach parse_commit_buffer about grafting.
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 (de180e) - I would expect to
also see d9af3c listed as parent, and the branch merging in here?
Am I missing something?
The graft info is not used by anything other than those that use
parse_commit() to figure out the commit ancestry information.
The list of commits that appear in the top pane of the gitk is
generated by git-rev-list which knows how to do it, but the
parent and child links, and the lines between nodes are drawn by
gitk using the information it reads directly from the commit
objects.
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.
[PATCH] Teach gitk to use grafts info
Finding commits to draw is done by git-rev-list which knows how
to do the grafts, but the lines between commits and the
parent / child links needs to be drawn by reading from the
commit objects. Teach that part of the code how to grok grafts
info so that fake ancestry is shown sensibly in gitk.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
gitk | 36 +++-
1 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -155,7 +155,7 @@ proc readcommit {id} {
}
proc parsecommit {id contents listed} {
-global commitinfo children nchildren parents nparents cdate ncleft
+global commitinfo children nchildren parents nparents cdate ncleft grafts
set inhdr 1
set comment {}
@@ -171,6 +171,23 @@ proc parsecommit {id contents listed} {
}
set parents($id) {}
set nparents($id) 0
+set has_graft [array get grafts $id]
+if { != $has_graft} {
+ set parents($id) $grafts($id)
+ set nparents($id) [llength $parents($id)]
+ foreach p $parents($id) {
+ if {![info exists nchildren($p)]} {
+ set children($p) {}
+ set nchildren($p) 0
+ set ncleft($p) 0
+ }
+ if {$listed [lsearch -exact $children($p) $id] 0} {
+ lappend children($p) $id
+ incr nchildren($p)
+ incr ncleft($p)
+ }
+ }
+}
foreach line [split $contents \n] {
if {$inhdr} {
if {$line == {}} {
@@ -178,6 +195,9 @@ proc parsecommit {id contents listed} {
} else {
set tag [lindex $line 0]
if {$tag == parent} {
+ if { != $has_graft} {
+ continue
+ }
set p [lindex $line 1]
if {![info exists nchildren($p)]} {
set children($p) {}
@@ -3194,6 +3214,20 @@ foreach arg $argv {
set history {}
set historyindex 0
+set grafts('') nothing
+array unset grafts ''
+if {![catch { set graft [exec cat [gitdir]/info/grafts] }]} {
+global grafts
+foreach line [split $graft \n] {
+ set commit [lindex $line 0]
+ set llen [llength $line]
+ set pp {}
+ for {set i 1} {$i $llen} {incr i} {
+ lappend pp [lindex $line $i]
+ }
+ set grafts($commit) $pp
+}
+}
set stopped 0
set redisplaying 0
-
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
Re: [PATCH] Teach parse_commit_buffer about grafting.
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 to send lines into hyperspace. Regards, Paul. - 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
Small team cogito/git setup
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 git internals. I find that using cogito is actually easier than cvs, and a mile easier than Arch (the two tools we use currently) and I rather keep it that way: simple. The upstream projects run on CVS, so I am setting up a repo fed by git-cvsimport for each of those. We all pull from that repo (cg-clone), so we can all see the upstream in its git representation. Now, we are going to run a few branches off that, and I want to have those branches _teamwide_ with the same name, so it is trivial for us to keep synching. All our work directories on our LAN will available via HTTP, so we can pull from the team repositories easily. Is there a good technique with cogito to have a team pull from each other, so that a single cg-update or cg-pull when working on a branch pulls from all my teammembers. Or are we forced to run an 'integration' repo so that we work with a 'star' arrangement? I am actually trying to avoid needing a central repo if possible. How should branch creation be handled for team-wide branches? I'd like to have branches use the same name across the team to avoid confusion. Phew. Every time I think I understand how things go with git, I find I don't know sh*t about it yet ;) martin - 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
Re: [PATCH] Teach parse_commit_buffer about grafting.
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 addition to all the other magic flags, there's a flag called --parents? Right now you use git-rev-list --header --topo-order, which gives you both the commit ID's and the header. Add a --parents there, and you'll notice that the first line of each NUL-terminated record changes from just the commit ID to the commit ID + parent list. That way gitk wouldn't need to actually know about grafts, because it would just pick it up from the git-rev-list output which gets it from the regular commit parsing code. Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ need to look at any other internal git information, you're probably doing something wrong, or you've missed yet another flag ;) Linus - 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
