* Re: Problem with cg-diff <file>
From: Junio C Hamano @ 2005-05-30 7:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050530003242.GA1036@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Ok, so this is what you get when you mix: sleepiness, performing only
PB> mental experiments not verified in practice, and inattentive reading of
PB> the code.
PB> I'm sorry for bothering. Instruct yourself from my bad example, please.
PB> :-)
If you forbid people to ask for help when the person who is
asked might feel the question groundless or based on "only
mental experiments not verified in practice and inattentive
reading of the code", the value to have a community diminishes.
We ask questions and ask for help because we know others know
more about things we do not know offhand, not necessarily
because we would not ever be able to figure them out ourselves.
If you know somebody else would know the answer immediately for
something that may take you a day or so to figure out, asking
for help is the right thing to do --- your time is better spent
on what you do best (e.g. improving Cogito). I should not feel
bothered by your questions, and I am certainly not feeling
bothered at all (well, at least until seeing the last sentence,
and wondering what you really meant ;-)).
Always glad to be of help.
^ permalink raw reply
* Re: More gitweb queries..
From: Junio C Hamano @ 2005-05-30 7:57 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050530013056.GH12290@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Note: If I pull into an empty tree (no HEAD) there is only one head in
TG> this array which corresponds to the remote_head. Otherwise the first
TG> element is *always* the local HEAD.
"An empty tree (no HEAD)"? Is your definition of "an empty
tree" the same as "empty" directory after you do "mkdir empty &&
cd empty && git-init-db", followed by bunch of git-*-pull to get
the objects and commits from other reposititories being involved
in the merge but without touching .git/HEAD? If so, why cannot
I do the git-*-pull from multiple repositories and merge them
together? Why "there is only one head in this array that is
remote_head"? Oh, I guess I am missing your definition of
"remote_head". Puzzled...
Anyhow I presume that if your ${GIT-.git}/HEAD exists, you
include it as the first element of MERGE_HEADS.
TG> I have a function merge which gets a sorted array of heads. Heads can be
TG> unlimited at the time because some of the heads can be included into
TG> other heads (they're a subset) and so they don't show up in the commit
TG> object. I call this array MERGE_HEADS.
Sorry I am not very good at this "thinking" thing, and I need to
draw pictures. Please bear with me.
(line of dev C)-------------C We are here, trying to merge
(line of dev B)---(merge)---B these three lines of devs:
(line of dev A)---A/ A, B and C
MERGE_HEADS = (A B C)
A is actually a "subset" of B
Is this what you mean by "subset"? Are these "subset" HEAD the
only thing that causes fast forwards?
My gut feeling without thinking much is that it might be easier
to first cull such fast forward heads by using N-way rev-tree
before you do anything else. If only one head survives after
that, then that head would be your new head and you do not have
to go through any merges. Otherwise you merge those independent
heads without worrying about fast forwards. How does that
sound?
^ permalink raw reply
* Re: [PATCH] cg-pull: summarize the number of pulled objects
From: Petr Baudis @ 2005-05-30 8:20 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20050530015650.GB10715@diku.dk>
Dear diary, on Mon, May 30, 2005 at 03:56:50AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Show cg-pull progress by summarizing the very verbose output of the pull
> backends into a continously updated line specifying the number of
> objects which have already been pulled.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
>
> Straight from the bloat department, perhaps, but it is nice to not have
> the terminal backlog ruined and the object count is quite nice too. :)
>
> Interesting, it counts 4950 objects when pulling over rsync and 4454
> objects when pulling locally. Didn't test HTTP pulling other than to see
> if the "got <sha>" lines was matched correctly.
It is nice, but actually losing information for me. It's ok for the HTTP
and SSH "smart pulls", but if I pull over rsync, I have progress
indication based on the first two digits - assuming roughly even
distribution of hashes, I can see that when I cross 80/ I'm in the half
etc. So what about showing some percentage or something in that case?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: -p diff output and the 'Index:' line
From: Petr Baudis @ 2005-05-30 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jhh6ty5.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 30, 2005 at 09:42:26AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> It's just something along the lines of "Me Og. Og sees /^+/. Og makes
> PB> the line green." written in gawk (actually I'm not sure if pure awk
> PB> wouldn't do, but I actually don't know the language), so I don't think
> PB> the external diff thing would've helped me with that in any way.
>
> Ah, I see. I thought you were talking about the Index: and
> separator lines. Colorizing diff/patch part, you need to parse
> the diff output with sed/awk/perl and annotate it anyway, and it
> does not matter if you annotate within GIT_EXTERNAL_DIFF or
> outside. I agree with you that using GIT_EXTERNAL_DIFF
> mechanism would not help you here.
Well, I want to finally converge with the diff format to what git uses.
So I'm just colorizing the /^diff --git/ line with a unusually bright
color, which will hopefully make up for the Index: and separator lines.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Problem with cg-diff <file>
From: Petr Baudis @ 2005-05-30 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing List
In-Reply-To: <7vfyw55eu2.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 30, 2005 at 09:54:13AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> Ok, so this is what you get when you mix: sleepiness, performing only
> PB> mental experiments not verified in practice, and inattentive reading of
> PB> the code.
>
> PB> I'm sorry for bothering. Instruct yourself from my bad example, please.
> PB> :-)
>
> If you forbid people to ask for help when the person who is
> asked might feel the question groundless or based on "only
> mental experiments not verified in practice and inattentive
> reading of the code", the value to have a community diminishes.
>
> We ask questions and ask for help because we know others know
> more about things we do not know offhand, not necessarily
> because we would not ever be able to figure them out ourselves.
>
> If you know somebody else would know the answer immediately for
> something that may take you a day or so to figure out, asking
> for help is the right thing to do --- your time is better spent
> on what you do best (e.g. improving Cogito).
Well, you definitively have a point. I just felt guilty that if I
would've spent ten seconds actually testing it, you wouldn't have to
spent ten minutes (or who knows how long) replying to my silly question.
> I should not feel bothered by your questions, and I am certainly not
> feeling bothered at all (well, at least until seeing the last
> sentence, and wondering what you really meant ;-)).
I meant you all on the mailing list, not you specifically. English is
sometimes annoying. ;-) (And I was just trying to be funny, in my usual
awful way.)
> Always glad to be of help.
Thanks. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: More gitweb queries..
From: Thomas Glanzmann @ 2005-05-30 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vmzqd4041.fsf@assigned-by-dhcp.cox.net>
Hello,
[ => Skip till next ']' if you want because my approach doesn't work out
for all cases in the optimal way.
> "An empty tree (no HEAD)"? Is your definition of "an empty
> tree" the same as "empty" directory after you do "mkdir empty &&
> cd empty && git-init-db", followed by bunch of git-*-pull to get
> the objects and commits from other reposititories being involved
> in the merge but without touching .git/HEAD?
Yep. In practice it isn't anything else than just using the first
'remote' HEAD as 'local' HEAD if there is no 'local' HEAD. But for merge
this doesn't really matter.
> If so, why cannot I do the git-*-pull from multiple repositories and
> merge them together? Why "there is only one head in this array that
> is remote_head"? Oh, I guess I am missing your definition of
> "remote_head". Puzzled...
My intention by writing this note was to clear things up. That it also
works for cases where you do the 'initial clone' for one and multiple
remotes.
> Anyhow I presume that if your ${GIT-.git}/HEAD exists, you
> include it as the first element of MERGE_HEADS.
Affirmative.
> TG> I have a function merge which gets a sorted array of heads. Heads can be
> TG> unlimited at the time because some of the heads can be included into
> TG> other heads (they're a subset) and so they don't show up in the commit
> TG> object. I call this array MERGE_HEADS.
Here is a typo: MERGE_HEADS is *not* sorted. But it is 'ordered'.
> Sorry I am not very good at this "thinking" thing, and I need to
> draw pictures. Please bear with me.
Of course, I do.
> (line of dev C)-------------C We are here, trying to merge
> (line of dev B)---(merge)---B these three lines of devs:
> (line of dev A)---A/ A, B and C
> MERGE_HEADS = (A B C)
> A is actually a "subset" of B
> Is this what you mean by "subset"? Are these "subset" HEAD the
> only thing that causes fast forwards?
Exactly, but it has not to be a merge it also can be a linear
development. What matters that A is referenced in any way in the history
of B.
In this case where A is referenced in the history of B, we just discard
HEAD A, because it is already merged. So A will never show up in
git-commit-tree in one of its "-p" options. But I mention it in the
commit-text as 'there was nothing todo'.
If we take now your example and switch the order A and B we have
MERGE_HEADS = (B A C) and A is still in the history of B:
We do exactly the same here only that in the above scenario we have to
kick out the previous COMMIT_HEAD when processing B while we drop the
current COMMIT_HEAD when processing A in this scenario. So to clear
things up:
The HEAD we are working on is surrouned by '*'s.
MERGE_HEADS = (*B* A C) => COMMIT_HEADS = (B)
MERGE_HEADS = (B *A* C) => COMMIT_HEADS = (B) /* note: A never did it in COMMIT_HEADS because it was referenced in history of B */
MERGE_HEADS = (B A *C*) => COMMIT_HEADS = (B C)
while in the above example with your initial order it is:
MERGE_HEADS = (*A* B C) => COMMIT_HEADS = (A)
MERGE_HEADS = (A *B* C) => COMMIT_HEADS = (B) /* note: A is kicked out of COMMIT_HEADS ... see above */
MERGE_HEADS = (A B *C*) => COMMIT_HEADS = (B C)
]
> My gut feeling without thinking much is that it might be easier
> to first cull such fast forward heads by using N-way rev-tree
> before you do anything else. If only one head survives after
> that, then that head would be your new head and you do not have
> to go through any merges. Otherwise you merge those independent
> heads without worrying about fast forwards. How does that
> sound?
You're right. Because this would work out bad (unneccessary
automatic/threeway/manual merge) if we twist MERGE_HEADS again:
MERGE_HEADS = (*C* A B) => COMMIT_HEADS (C)
MERGE_HEADS = (C *A* B) => COMMIT_HEADS (C A) /* A stays in because it is not in the history of C; -> unneccessary merge */
MERGE_HEADS = (C A *B*) => COMMIT_HEADS (C A B)
Okay, so I have to elminate all fast forward conditions in the first
place? How do I do this:
foreach CURRENT_HEAD (@MERGE_HEADS) {
foreach COMPARE_HEAD (@MERGE_HEADS) {
if (COMPARE_HEAD != CURRENT_HEAD
&& COMPARE_HEAD is_included_into_history_of CURRENT_HEAD) {
@WIPE_HEADS += COMPARE_HEAD;
}
}
}
foreach (@WIPE_HEADS) {
grep -v @WIPE_HEADS @MERGE_HEADS;
}
Thomas
^ permalink raw reply
* Re: [PATCH] Cleanup cogito command usage reporting
From: Petr Baudis @ 2005-05-30 8:45 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20050530030521.GA13232@diku.dk>
Dear diary, on Mon, May 30, 2005 at 05:05:21AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> [ Sorry for the resend. This should bring all usage strings in sync. I
> forgot to add the new options. ]
>
> - Synchronize usage strings with those in cg-help. The command
> identifiers are still not as descriptive, though.
Ok, I'll focus on this point (the rest seems fine). I think it's
inferior this way, since you are losing information, and for no benefit.
> diff --git a/cg-clone b/cg-clone
> --- a/cg-clone
> +++ b/cg-clone
> @@ -15,11 +15,12 @@
> -USAGE="cg-clone [-s] LOCATION [<directory>]"
> +USAGE="cg-clone [-s] LOCATION [DESTINATION]"
> @@ -30,7 +31,7 @@ if [ "$1" = "-s" ]; then
> fi
>
> location=$1
> -[ "$location" ] || die "usage: cg-clone [-s] SOURCE_LOC [DESTDIR]"
> +[ "$location" ] || usage
LOCATION -> SOURCE_LOC is fine in this context (if we would ever want
DEST_LOC, it would be better to stick with SOURCE_LOC, though). But
DESTDIR->DESTINATION is losing information. In cogito.txt you describe
DESTINATION as a general target location, but it's really a directory
here. And it's shorter.
> diff --git a/cg-export b/cg-export
> --- a/cg-export
> +++ b/cg-export
> @@ -22,7 +22,7 @@ USAGE="cg-export DESTINATION [TREE]"
> dest=$1
> id=$(tree-id $2)
>
> -([ "$dest" ] && [ "$id" ]) || die "usage: cg-export DEST [TREE_ID]"
> +([ "$dest" ] && [ "$id" ]) || usage
I'm for DESTDIR here too, and what harm does the _ID part make here? I
think it's non-obvious otherwise - "TREE" can be understood as some
directory name too.
> diff --git a/cg-help b/cg-help
> --- a/cg-help
> +++ b/cg-help
> @@ -43,7 +43,7 @@ Available commands:
> cg-export DEST [TREE_ID]
> cg-help [COMMAND]
> cg-init
> - cg-log [-c] [-f] [-m] [-r FROM_ID[:TO_ID]] [FILE]...
> + cg-log [-c] [-f] [-m] [-uUSERNAME] [-r FROM_ID[:TO_ID]] [FILE]...
> cg-ls [TREE_ID]
> cg-merge [-c] [-b BASE_ID] FROM_ID
> cg-mkpatch [-m] [-s] [-r FROM_ID[:TO_ID]]
So what about bringing those in sync too? (Or alternatively letting it
be now and build the output dynamically in another patch.)
> diff --git a/cg-merge b/cg-merge
> --- a/cg-merge
> +++ b/cg-merge
> @@ -38,11 +38,11 @@ fi
> base=
> if [ "$1" = "-b" ]; then
> shift
> - [ "$1" ] || die "usage: cg-merge [-c] [-b BASE_ID] FROM_ID"
> + [ "$1" ] || usage
I think BASE_ID->REVISION is loosing information too. What about
BASE_COMMIT or something?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: More gitweb queries..
From: Thomas Glanzmann @ 2005-05-30 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050530083653.GL12290@cip.informatik.uni-erlangen.de>
Hello,
I also have to strip duplicate HEADs out. So we do the following:
run 0: kill dups
run 1: kill HEADs which are referenced in the history of other HEADs
run 2: do the merging (still don't know to what I should set the local
HEAD to the 'left' or 'right' part. Maybe we should create temporary
commit object so that 'merge-base' can better work on them?
Thomas
^ permalink raw reply
* Re: More gitweb queries..
From: Junio C Hamano @ 2005-05-30 10:20 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050530092140.GQ12290@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Hello,
TG> I also have to strip duplicate HEADs out. So we do the following:
TG> run 0: kill dups
TG> run 1: kill HEADs which are referenced in the history of other HEADs
I think merge-base between A and A is always A, so the second
pass would eliminate the dups anyway...
^ permalink raw reply
* Re: More gitweb queries..
From: Thomas Glanzmann @ 2005-05-30 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vhdgl2ext.fsf@assigned-by-dhcp.cox.net>
Hello,
> I think merge-base between A and A is always A, so the second pass
> would eliminate the dups anyway...
two scenarios come into my mind which could clash (second ommited
because it would rely that the 'local' HEAD is changes on threeway
merge)
consider the follow MERGE_HEADS = (A B B)
/----- A
/
-GCA------ B
Now B gets twice automatic/threeway/manual merged into A which is just
stupid and couldn't work out.
------------------------------------------------------------------------------
But I still don't know how to handle the following scenario:
/----- A
/
-GCA------GCA---- B
\---- C
MERGES_HEAD = (A B C). I think the best way would be introduce a
temporary commit object otherwise C into AB merge would have merge_base
on the first GCA which is suboptimal and maybe wrong isn't it?
/----- A -------D---E
/ / /
-GCA------GCA---- B /
\------- C
Where D is a temporary COMMIT obeject to use the second GCA to merge C
with D and gets E.
Gruesse,
Thomas
^ permalink raw reply
* cg-update with local uncommitted changes
From: Marcel Holtmann @ 2005-05-30 14:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
Hi Petr,
when doing a cg-update and I have local uncommitted changes it fails
with the "... needs update" message. From some previous posts on the
mailing list I got the impression that it is possible to pull updates
into the local repository with changed files. At the moment I am using
the following sequence:
cg-diff > patch
cg-cancel
cg-update origin
cat patch | patch -p1
rm patch
The problem with this sequence is when I have added or removed files
from my repository. This needs a lot of manual fixing.
With Bitkeeper it was possible to pull changes as long as they don't
affect local uncommitted files.
Any ideas on how to implement or if it exists on how to use it?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] cg-pull: summarize the number of pulled objects
From: Jonas Fonseca @ 2005-05-30 15:09 UTC (permalink / raw)
To: Frank Sorenson; +Cc: Petr Baudis, git
In-Reply-To: <429A8D21.70609@tuxrocks.com>
Frank Sorenson <frank@tuxrocks.com> wrote Sun, May 29, 2005:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonas Fonseca wrote:
> > + if [ "$last_objects" != "$objecst" ]; then
> ^^^^^^^^
> Did you mean 'objects' ???
>
> > + last_objects=$objects
> > + echo;
> > + fi
> > + echo "$line"
> > + ;;
> > + esac
> > + done;
> > + [ "$last_objects" != "$objecst" ] && echo
> ^^^^^^^
> Here too?
Yes. Thanks.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] cg-pull: summarize the number of pulled objects
From: Jonas Fonseca @ 2005-05-30 15:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050530082054.GB1036@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote Mon, May 30, 2005:
> Dear diary, on Mon, May 30, 2005 at 03:56:50AM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> told me that...
> > Show cg-pull progress by summarizing the very verbose output of the pull
> > backends into a continously updated line specifying the number of
> > objects which have already been pulled.
> >
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> > ---
> >
> > Straight from the bloat department, perhaps, but it is nice to not have
> > the terminal backlog ruined and the object count is quite nice too. :)
> >
> > Interesting, it counts 4950 objects when pulling over rsync and 4454
> > objects when pulling locally. Didn't test HTTP pulling other than to see
> > if the "got <sha>" lines was matched correctly.
>
> It is nice, but actually losing information for me. It's ok for the HTTP
> and SSH "smart pulls", but if I pull over rsync, I have progress
> indication based on the first two digits - assuming roughly even
> distribution of hashes, I can see that when I cross 80/ I'm in the half
> etc. So what about showing some percentage or something in that case?
[ Ok, I've done the percentage thing. The number of bytes are also
tracked. I also tried to return the correct exit code from the pull
function using PIPESTATUS. ]
[PATCH] cg-pull: summarize the number of pulled objects
Show object pulling progress by summarizing the verbose output of the
pull backends into a single continously updated status line. It displays
the number of already pulled objects, the total size of the pulled
objects and for rsync the percentage done based on what object
sub-directory objects are coming from. The last thing means it might not
always get all the way up to 100%.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
cg-pull | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -29,6 +29,49 @@ if echo "$uri" | grep -q '#'; then
uri=$(echo $uri | cut -d '#' -f 1)
fi
+pull_progress() {
+ percentage=""
+ objects=0
+ last_objects=0
+ size=0
+
+ while read line; do
+ object=
+
+ case "$line" in
+ link*|symlink*|\
+ "got "[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]*)
+ # Convert the sha to an object path
+ object=$(echo "$line" | sed 's,.* \([a-f0-9][a-f0-9]\),\1/,')
+ ;;
+
+ [a-f0-9][a-f0-9]/[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]*)
+ object="$line"
+ # Estimate percentage done using the position of
+ # the object subdir. It might not get all the way
+ # up to 100% ...
+ position=$(echo "$line" | cut -d/ -f 1)
+ percentage=", $((0x$position * 100 / 0xff))% done"
+ ;;
+
+ *)
+ if [ "$last_objects" != "$objects" ]; then
+ last_objects="$objects"
+ echo;
+ fi
+ echo "$line"
+ continue
+ ;;
+ esac
+
+ object="$_git_objects/$object"
+ size=$(($size + $(stat -c '%s' "$object" 2>/dev/null)))
+ objects=$(($objects + 1));
+
+ echo -ne "progress: $objects objects, $size bytes$percentage\r"
+ done;
+ [ "$last_objects" != "$objects" ] && echo
+}
fetch_rsync () {
redir=
@@ -62,7 +105,8 @@ fetch_rsync () {
}
pull_rsync () {
- fetch_rsync -s -u -d "$2/objects" "$_git_objects"
+ fetch_rsync -s -u -d "$2/objects" "$_git_objects" | pull_progress
+ return ${PIPESTATUS[0]}
}
@@ -107,7 +151,8 @@ fetch_http () {
}
pull_http () {
- git-http-pull -a -v "$(cat "$_git/refs/heads/$1")" "$2/"
+ (git-http-pull -a -v "$(cat "$_git/refs/heads/$1")" "$2/" 2>&1 /dev/null) | pull_progress
+ return ${PIPESTATUS[0]}
}
@@ -142,7 +187,8 @@ fetch_ssh () {
}
pull_ssh () {
- git-rpull -a -v "$(cat "$_git/refs/heads/$1")" "$2"
+ (git-rpull -a -v "$(cat "$_git/refs/heads/$1")" "$2" 2>&1 /dev/null) | pull_progress
+ return ${PIPESTATUS[0]}
}
@@ -170,7 +216,8 @@ fetch_local () {
}
pull_local () {
- git-local-pull -a -l -v "$(cat "$_git/refs/heads/$1")" "$2"
+ (git-local-pull -a -l -v "$(cat "$_git/refs/heads/$1")" "$2" 2>&1 /dev/null) | pull_progress
+ return ${PIPESTATUS[0]}
}
if echo "$uri" | grep -q "^http://"; then
--
Jonas Fonseca
^ permalink raw reply
* Problem with cg-update and deleted files
From: Marcel Holtmann @ 2005-05-30 15:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
Hi Petr,
with the latest cg-update and pulling the linux-2.6 repository I saw
problems with deleted files:
Applying changes...
Fast-forwarding 37e0915b701281182cea9fc90e894d10addf134a -> 5e485b7975472ba4a408523deb6541e70c451842
on top of 37e0915b701281182cea9fc90e894d10addf134a...
rm: cannot remove `:100644 000000 057cc3f8ff378c0de881482d55b47255e3c5ea72 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 d1352120acd7ef7853041098bf12ae79a8ac1e0a 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 abdb015a4d71036eb7305e18b606151eb35fb810 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 fc568af468b9482b9e09cc618d726ece226cb9db 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 cb90681e151cd510825dd8f7ca555ad8e0be137f 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 c91976274e7b007b78269e40fd8b354a4e888b86 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 57d03d9178f611f73079d6a83af0302f9c33dc3c 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 a7ffd9c45a2c272594a0be593cdaa467ce7abf5e 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 98fa3f7a9eff4721531ca060cee5961f7fba0100 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 5b2aacdefa6cb7db6d3aa87194f210d5fcb87974 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 D': No such file or directory
rm: cannot remove `:100644 000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 D': No such file or directory
Regards
Marcel
^ permalink raw reply
* [PATH] cg-Xlib: Fix problem with cg-update and deleted files
From: Jonas Fonseca @ 2005-05-30 16:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1117466600.7072.188.camel@pegasus>
Marcel Holtmann <marcel@holtmann.org> wrote Mon, May 30, 2005:
> with the latest cg-update and pulling the linux-2.6 repository I saw
> problems with deleted files:
Update tree_timewarp()s git-diff-tree logic to handle the diff-format
header and file both being NUL separated.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
I've only tested it in a small test script ...
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -73,10 +73,15 @@ tree_timewarp () {
echo "$branch" > $_git/HEAD
# Kill gone files
- git-diff-tree -z -r $base $branch | egrep -z '^:([^ ][^ ]* ){4}D' | xargs -0 bash -c '
+ git-diff-tree -r $base $branch | xargs -0 bash -c '
while [ "$1" ]; do
- rm -- "$(echo "$1" | cut -f 2)"
- shift
+ header="$1"; shift
+ file="$1"; shift
+
+ # match ":100755 000000 14d43b1abf... 000000000... D"
+ if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
+ rm -- "$file"
+ fi
done
' padding
git-checkout-cache -f -a
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATH] cg-Xlib: Fix problem with cg-update and deleted files
From: Jonas Fonseca @ 2005-05-30 16:43 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <20050530163957.GC28681@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote Mon, May 30, 2005:
> Marcel Holtmann <marcel@holtmann.org> wrote Mon, May 30, 2005:
> > with the latest cg-update and pulling the linux-2.6 repository I saw
> > problems with deleted files:
>
> I've only tested it in a small test script ...
... which of course is no the best thing. Here's one with -z option.
Update tree_timewarp()s git-diff-tree logic to handle the diff-format
header and file both being NUL separated.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -73,10 +73,15 @@ tree_timewarp () {
echo "$branch" > $_git/HEAD
# Kill gone files
- git-diff-tree -z -r $base $branch | egrep -z '^:([^ ][^ ]* ){4}D' | xargs -0 bash -c '
+ git-diff-tree -z -r $base $branch | xargs -0 bash -c '
while [ "$1" ]; do
- rm -- "$(echo "$1" | cut -f 2)"
- shift
+ header="$1"; shift
+ file="$1"; shift
+
+ # match ":100755 000000 14d43b1abf... 000000000... D"
+ if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
+ rm -- "$file"
+ fi
done
' padding
git-checkout-cache -f -a
--
Jonas Fonseca
^ permalink raw reply
* Re: [COGITO PATCH] Fix cg-log and cg-status for non-GNU sed/sort
From: Alecs King @ 2005-05-30 17:00 UTC (permalink / raw)
To: git
In-Reply-To: <20050529234911.GZ1036@pasky.ji.cz>
On Mon, May 30, 2005 at 01:49:11AM +0200, Petr Baudis wrote:
> > > > - echo; sed -re '
> > > > - /
> > > *Signed-off-by:.*/Is//'$colsignoff'&'$coldefault'/
> > > > - /
> > > *Acked-by:.*/Is//'$colsignoff'&'$coldefault'/
> > > > - s/./ &/
> > > > - '
> > > > + echo; sed -e "/
> > > > *Signed-off-by:.*/s/
> > > *Signed-off-by:.*/$colsignoff&$coldefault/" -e"/
> > > > +*Acked-by:.*/s/ *Acked-by:.*/$colsignoff&$coldefault/" -e "s/./
> > > > &/"
> > > > +
> > >
> > > Is it necessary to take away the newlines? What is the real
> > > problem,
> > > actually? Just the I flag?
> >
> > Is it strictly necessary to take away the newlines? I don't know. To
> > be honest, I didn't
> > experiment too much with alternate implementations. But the I flag
> > in the sed script,
> > yes that is not understood by non-GNU sed. And the "-r" to sed
> > itself is also
> > problematic.
>
> I think we don't really need -r anyway. Could you please try with the
> 'i' flag instead of 'I'? (The manpage is somewhat unclear on the
> difference and portability.) Also, could you try if it works with the
> newlines?
-r here is for the 'I' (same as 'i') modifier, which means case
insensitive. non-GNU sed might not have the '-r' option or the 'I'
('i') modifier.
I dunno about the strict rules of 'Signed-off-by' things but what i have
seen are all _exactly_ of this form. I have never seen something like
'SIGNED-OFF-BY' or 'sIGneD-oFf-bY'.
If only the exact case sensitive form is allowed, then we can safely
remove the '-r' and 'I'.
Also, to Mark, as a quick alternative to work around these sed issues,
you can install the gsed port. IIRC, opendarwin has this port.
Speaking of other portability issues, i made up a patch to make cogito
properly work under fbsd (without hurting others hopefully) weeks ago:
1) expr would regard a negative $dtz as an option (-xx).
2) coloring for both terminfo & termcap terminal.
Index: cg-Xlib
===================================================================
--- de641904363cd3759f132ee7c0dfaf8a2ee58388/cg-Xlib (mode:100755)
+++ 4e3c899dfa4a74effdb4ae23528785b8f688561d/cg-Xlib (mode:100755)
@@ -43,7 +43,7 @@
date="$1"
sec=${date[0]}; tz=${date[1]}
dtz=${tz/+/}
- lsec=$(expr $dtz / 100 \* 3600 + $dtz % 100 \* 60 + $sec)
+ lsec=$(expr \( $dtz \) / 100 \* 3600 + \( $dtz \) % 100 \* 60 +
$sec)
pdate="$(date -Rud "1970-01-01 UTC + $lsec sec" 2>/dev/null)"
echo "${pdate/+0000/$tz}"
Index: cg-log
===================================================================
--- de641904363cd3759f132ee7c0dfaf8a2ee58388/cg-log (mode:100755)
+++ 4e3c899dfa4a74effdb4ae23528785b8f688561d/cg-log (mode:100755)
@@ -42,13 +42,14 @@
# TODO: Parse -r here too.
case "$1" in
-c)
- # See terminfo(5), "Color Handling"
- colheader="$(tput setaf 2)" # Green
- colauthor="$(tput setaf 6)" # Cyan
- colcommitter="$(tput setaf 5)" # Magenta
- colfiles="$(tput setaf 4)" # Blue
- colsignoff="$(tput setaf 3)" # Yellow
- coldefault="$(tput op)" # Restore default
+ # ANSI escape seq
+ esc=$(echo -e '\e')
+ colheader="${esc}[0;32m" # Green
+ colauthor="${esc}[0;36m" # Cyan
+ colcommitter="${esc}[0;35m" # Magenta
+ colfiles="${esc}[0;34m" # Blue
+ colsignoff="${esc}[0;33m" # Yellow
+ coldefault="${esc}[0m" # Restore default
shift
;;
-f)
--
Alecs King
^ permalink raw reply
* Re: More gitweb queries..
From: Junio C Hamano @ 2005-05-30 17:54 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050530121100.GS12290@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
Disregard my last MB(A,A)===A thing. I really was not thinking,
but in N-way merge I think rev-tree is your friend. Unlike
merge-base which always does two heads at a time, rev-tree works
N-way. You should be able to give many heads to it and have it
help you figure out the ancestory relationship across them.
TG> But I still don't know how to handle the following scenario:
TG> /----- A
TG> /
TG> -GCA#1---GCA#2--- B
TG> \---- C
TG> MERGES_HEAD = (A B C). I think the best way would be introduce a
TG> temporary commit object otherwise C into AB merge would have merge_base
TG> on the first GCA which is suboptimal and maybe wrong isn't it?
I think you can run the same algorithm for those pairwise
ancestors and favor the less common ones. In the above drawing,
you would first find out the three common pair-wise ancestors.
In your drawing,
GCA(A,B) = GCA#1
GCA(B,C) = GCA#2
GCA(C,A) = GCA#1
GCA(GCA#1,GCA#2) = GCA#1
Then you notice that GCA#2 is less common than GCA#1 (indeed
GCA#1 is contained in GCA#2). So favoring the GCA#2, you do the
merge pair that uses it as the merge base, namely B and C,
first.
You scan the pairwise list again and find the pair that have not
merged and uses the least common GCA as merge base and keep
going. For the definition of less common, in many cases those
GCA#n would not be related at all and cannot be compared by
topology only, so you would probably need to come up with a
heuristics to break such ties. Off the top of my head, you
could compare commit timestamps (prefer younger), sum of commit
chain length from GCA#n to its two head pairs (prefer shorter),
sum of number of changed files from GCA#n to its two head pairs
(prefer smaller).
TG> /----- A -------D---E
TG> / / /
TG> -GCA------GCA---- B /
TG> \------- C
TG> Where D is a temporary COMMIT obeject to use the second GCA to merge C
TG> with D and gets E.
Yes, if you ended up merging A and B first you would have
something like that. I think you should not do that in the
first place, and try to merge the "most recently diverged" pair
first, like this:
/----- A -----------Y
/ /
-GCA#1---GCA#2--- B --X
\---- C -/
If we are still talking about Octopus (Tripus in this case), you
would not want to actually make a commit X. When you merge B
and C, you consider that such a resulting tree resides at GCA#2
(merge base of B and C) for the purposes of further merge
computation. Then you merge that resulting tree with A, using
GCA#1.
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Petr Baudis @ 2005-05-30 18:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1117463114.7072.185.camel@pegasus>
Dear diary, on Mon, May 30, 2005 at 04:25:14PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
Hello,
> when doing a cg-update and I have local uncommitted changes it fails
> with the "... needs update" message. From some previous posts on the
> mailing list I got the impression that it is possible to pull updates
> into the local repository with changed files. At the moment I am using
> the following sequence:
>
> cg-diff > patch
> cg-cancel
> cg-update origin
> cat patch | patch -p1
> rm patch
>
> The problem with this sequence is when I have added or removed files
> from my repository. This needs a lot of manual fixing.
>
> With Bitkeeper it was possible to pull changes as long as they don't
> affect local uncommitted files.
>
> Any ideas on how to implement or if it exists on how to use it?
does it really fail? "... needs update" is not an error but something
between informative and warning message. (I've just committed a change
which silences it in this case.)
If the update did indeed fail, could you show the complete output,
please?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Marcel Holtmann @ 2005-05-30 19:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050530183932.GB10439@pasky.ji.cz>
Hi Petr,
> > when doing a cg-update and I have local uncommitted changes it fails
> > with the "... needs update" message. From some previous posts on the
> > mailing list I got the impression that it is possible to pull updates
> > into the local repository with changed files. At the moment I am using
> > the following sequence:
> >
> > cg-diff > patch
> > cg-cancel
> > cg-update origin
> > cat patch | patch -p1
> > rm patch
> >
> > The problem with this sequence is when I have added or removed files
> > from my repository. This needs a lot of manual fixing.
> >
> > With Bitkeeper it was possible to pull changes as long as they don't
> > affect local uncommitted files.
> >
> > Any ideas on how to implement or if it exists on how to use it?
>
> does it really fail? "... needs update" is not an error but something
> between informative and warning message. (I've just committed a change
> which silences it in this case.)
>
> If the update did indeed fail, could you show the complete output,
> please?
I used the latest cg-update on a test repository and now it works, but I
found odd cases when I have files added/deleted that are not committed
yet. For the added case I saw this:
Warning: uncommitted local changes, trying to bring them forward
The next patch would create the file test.c,
which already exists! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file test.c.rej
Adding file test.c
I also think that it would be great if we cancel the merge if the local
changes conflict with the files in the merge. This is how Bitkeeper does
it and I think it is the only safe way, because if something fails or
rejects we may destroy the local changes.
Regards
Marcel
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Zack Brown @ 2005-05-30 19:25 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1117463114.7072.185.camel@pegasus>
On Mon, May 30, 2005 at 04:25:14PM +0200, Marcel Holtmann wrote:
> Hi Petr,
>
> when doing a cg-update and I have local uncommitted changes it fails
> with the "... needs update" message.
I don't see failures, but I do see the "needs update" message often when
I do cg-update. If I run cg-update a second time it says the tree is fully
up-to-date. However, if I then do a cg-diff, I will see tons of diff output.
This is on a tree (the kernel) that I haven't modified at all, I only track it
with cg-update.
I also track Cogito, and I use the latest form of all git and Cogito tools.
Maybe somewhere along the line I've corrupted my repo by using incompatible
versions of the git/Cogito toolset.
I've noticed if I do a fresh cg-clone the problem seems to go away.
Be well,
Zack
> From some previous posts on the
> mailing list I got the impression that it is possible to pull updates
> into the local repository with changed files. At the moment I am using
> the following sequence:
>
> cg-diff > patch
> cg-cancel
> cg-update origin
> cat patch | patch -p1
> rm patch
>
> The problem with this sequence is when I have added or removed files
> from my repository. This needs a lot of manual fixing.
>
> With Bitkeeper it was possible to pull changes as long as they don't
> affect local uncommitted files.
>
> Any ideas on how to implement or if it exists on how to use it?
>
> Regards
>
> Marcel
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Marcel Holtmann @ 2005-05-30 19:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <1117480796.7072.204.camel@pegasus>
Hi Petr,
> > > when doing a cg-update and I have local uncommitted changes it fails
> > > with the "... needs update" message. From some previous posts on the
> > > mailing list I got the impression that it is possible to pull updates
> > > into the local repository with changed files. At the moment I am using
> > > the following sequence:
> > >
> > > cg-diff > patch
> > > cg-cancel
> > > cg-update origin
> > > cat patch | patch -p1
> > > rm patch
> > >
> > > The problem with this sequence is when I have added or removed files
> > > from my repository. This needs a lot of manual fixing.
> > >
> > > With Bitkeeper it was possible to pull changes as long as they don't
> > > affect local uncommitted files.
> > >
> > > Any ideas on how to implement or if it exists on how to use it?
> >
> > does it really fail? "... needs update" is not an error but something
> > between informative and warning message. (I've just committed a change
> > which silences it in this case.)
> >
> > If the update did indeed fail, could you show the complete output,
> > please?
>
> I used the latest cg-update on a test repository and now it works
let me be more specific. It only works in the fast forward case. If we
actually must merge the trees, because I have local committed changes
and not committed changes, I see this:
link 74966c42ddd874192c318acfc5f013e56c50606a
link b27ddcd47e293557e0605b98b2a1e8429035cdc5
link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
:100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M README
Applying changes...
usage.c: needs update
cg-merge: merge blocked: local changes
I changed the README in test1 repository and committed it. Then I
changed Makefile in test2 repository and committed it. After that I
modified usage.c and left it uncommitted. Then I pulled in the README
change from test1 repository.
Regards
Marcel
^ permalink raw reply
* [gitweb PATCH] Kill warnings in Webserver Error Log
From: Jochen Roemling @ 2005-05-30 19:34 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
The following patch kills two warnings in the Web Server Error Log:
[Mon May 30 21:24:15 2005] gitweb.cgi: "my" variable %co masks earlier
declaration in same scope at /home/www/html/tools/cgi-bin/gitweb.cgi
line 1658.
[Mon May 30 21:25:46 2005] gitweb.cgi: "my" variable %co masks earlier
declaration in same scope at /home/www/html/tools/cgi-bin/gitweb.cgi
line 1615.
There might be a patch offset of few lines because I deleted my local
gitweb settings from the patch.
Signed-off-by: Jochen Roemling <jochen@roemling.net>
--- /cgi-bin/gitweb.cgi.2 2005-05-29 17:23:10.000000000 +0200
+++ cgi-bin/gitweb.cgi 2005-05-30 21:26:44.000000000 +0200
@@ -1616,7 +1618,7 @@
}
my @commit_lines = split "\n", $commit_text;
my $commit = shift @commit_lines;
- my %co = git_read_commit($commit, \@commit_lines);
+ %co = git_read_commit($commit, \@commit_lines);
if (!%co) {
next;
}
@@ -1653,7 +1655,6 @@
$/ = "\n";
open $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree
-r --stdin -S$searchtext";
$alternate = 0;
- my %co;
my @files;
while (my $line = <$fd>) {
if (%co && $line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40})
([0-9a-fA-F]{40}) (.)\t(.*)$/) {
^ permalink raw reply
* I want to release a "git-1.0"
From: Linus Torvalds @ 2005-05-30 20:00 UTC (permalink / raw)
To: Git Mailing List
Ok, I'm at the point where I really think it's getting close to a 1.0, and
make another tar-ball etc. I obviously feel that it's already way superior
to CVS, but I also realize that somebody who is used to CVS may not
actually realize that very easily.
So before I do a 1.0 release, I want to write some stupid git tutorial for
a complete beginner that has only used CVS before, with a real example of
how to use raw git, and along those lines I actually want the thing to
show how to do something useful.
So before I do that, is there something people think is just too hard for
somebody coming from the CVS world to understand? I already realized that
the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
to put into a sane tutorial.
I was showing off raw git to Steve Chamberlain yesterday, and showing it
to him made some things pretty obvious - one of them being that
"git-init-db" really needed to set up the initial refs etc). So I wrote
this silly "git-commit-script" to make it at least half-way palatable, but
what else do people feel is "too hard"?
I think I'll move the "cvs2git" script thing to git proper before the 1.0
release (again, in order to have the tutorial able to show what to do if
you already have an existing CVS tree), what else?
Linus
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: jeff millar @ 2005-05-30 20:33 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
Linus Torvalds wrote:
>So before I do that, is there something people think is just too hard for
>somebody coming from the CVS world to understand?
>
I'm a fairly clueless cvs user, trying to use cg/git as a way to track a
single
user project...using cogito, because that's easier, right?
The usage pattern that causing me problems right now.
cg-init a whole directory tree (trying with /etc and a software project
directory)
note that too many files got included (*.cache, *.backup, *.o, binaries,
etc)
want to stop tracking them, cg-rm also removes the file, don't want that.
What's the best way to stop tracking files?
jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox