* Re: Git User's Survey 2007 unfinished summary continued
From: Federico Mena Quintero @ 2007-10-22 14:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710200035020.25221@racer.site>
On Sat, 2007-10-20 at 00:37 +0100, Johannes Schindelin wrote:
> FWIW try this:
>
> git<Space><Tab>
>
> or even better:
>
> git<Enter>
Hmm, this didn't work. I'm still using git 1.5.4.2 from the
stock openSUSE 10.3 packages --- did this get added in a newer version?
Federico
^ permalink raw reply
* Re: [PATCH] don't set-group-id on directories on apple
From: Johannes Schindelin @ 2007-10-22 14:16 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071022075459.GA1157@srparish.net>
Hi,
On Mon, 22 Oct 2007, Scott R Parish wrote:
> "git init --shared=all" was failing because chmod was returning
> EPERM.
Not here. This is git version 1.5.3.rc4.1716.gc3498, and "uname -a" says
Darwin michael-stirrats-mac-mini.local 8.10.0 Darwin Kernel Version
8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC
Power Macintosh powerpc
Is it possible that you have stricter permission settings? Or that you
try to re-initialise a repository that somebody else initialised
originally?
Ciao,
Dscho
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Karl Hasselström @ 2007-10-22 14:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Michael Witten, Shawn O. Pearce, git
In-Reply-To: <87ACA689-CBBD-4E6D-9BAD-B3BBA8391DB9@wincent.com>
On 2007-10-20 13:15:19 +0200, Wincent Colaiuta wrote:
> I think the issue here is that git-mv as it is currently implemented
> really conflates two things:
>
> 1. Renaming a file in the traditional "mv" sense
> 2. Staging the entire contents of the file in the index, ready or not
>
> So it's kind of like the command were called git-mv-and-add or git-
> rename-and-add. And given that the index as a staging area is such a
> central content in Git, users often want to have more control over
> what gets added to the index than that; ie. "I really just wanted to
> rename the file, and leave the staging of modifications to the
> content up to me".
I've come to that conclusion too while reading this thread. It would
make more sense for git-mv to, as others have already suggested, move
the file in the worktree and move the file in the index but _not_ add
workdir updates to the index. git-mv --cached would do only the index,
and not touch the worktree.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Karl Hasselström @ 2007-10-22 14:00 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Ari Entlich, Michael Witten, git
In-Reply-To: <20071020064003.GA30605@coredump.intra.peff.net>
On 2007-10-20 02:40:03 -0400, Jeff King wrote:
> Right. So the exact state you have in your index never actually
> existed in your working tree. But that's OK if:
> - the changes are trivial and obviously correct
> - you're not actually planning on _committing_ that, you just want
> to build the commit using the index
Or
- you plan to revisit the commit at a later time and verify that
it's OK
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <471C9B13.9080603@op5.se>
Hi,
On Mon, 22 Oct 2007, Andreas Ericsson wrote:
> If I were to suggest any improvements, it'd be to change the semantics of
> git-pull to always update the local branches set up to be merged with the
> remote tracking branches when they, prior to fetching, pointed to the same
> commit, such that when
>
> $ git show-ref master
> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>
> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
In general, this should fail. Because you are expected to have local
changes in the local branches. What you describe suggests that you should
not use the branch name "master" at all, but "origin/master".
That said, there is a pretty simple way to achieve what you want (even if
it does not help the confusion you create between local and remote
branches):
git config --add remote.origin.fetch master:master
Of course, when you checkout "master" and pull then, you'll get even more
problems, _exactly_ because you muddled up the clear distinction between
local and remote branches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Pierre Habouzit @ 2007-10-22 13:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <471C950E.40702@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Mon, Oct 22, 2007 at 12:18:22PM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >On Mon, Oct 22, 2007 at 11:35:30AM +0000, Johannes Sixt wrote:
> >>Pierre Habouzit schrieb:
> >>>On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
> >>>>Pierre Habouzit schrieb:
> >>>>>+say_color () {
> >>>>>+ [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
> >>>>>+ shift
> >>>>>+ echo "* $*"
> >>>>>+ tput op
> ^^^^^^^^
> I am talking about this line.
Oooh, good catch :P it should be guarded by a [ "$nocolor" = 0 ]
indeed :P (or use your solution).
> >>>>>+}
> >>I wanted to point out that if tput is not available, the second
> >>invocation will leave "tput: command not found" behind on stderr.
> >>Therefore, I proposed to make the definition of say_color() different
> >>depending on whether $color is set or not. Then you don't need to test
> >>for $color twice inside the function.
> > Right we can do that. I'll try to rework the patch. and no it
> >shouldn't leave tput: command not found as I 2>/dev/null and I think the
> >shell doesn't print that in that case. At least my zsh doesn't.
>
> There is no 2>/dev/null. Am I missing something?
I was.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Ericsson, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com>
Hi,
On Mon, 22 Oct 2007, Jakub Narebski wrote:
> On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
> [...]
> >>>>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>>>>
> >>>>>> Maybe we could group commands into more categories?
>
> > Similarly, it might be helpful to have help topics the gdb way, like
> > "git help patches". It's one of those things that people have come to
> > expect from a software tool, so perhaps we should humor them? Given gits
> > "every help topic is a man-page" idiom, this shouldn't require any real
> > technical effort.
> >
> > Such topics should probably include
> > merge/merges/merging - overview of various ways of putting two lines of
> > development back together
> > patch/patches - how to create, send and apply
> > tags/branches/refs - what they are, why they're good, link to merging
>
> Very good idea. It is definitely something that can be worked on.
>
> By the way, what do you think about "spying" version of git, specially
> marked release which gathers statistics of porcelain used, with
> frequency of its use, and git-sendstats command added in this release?
I like Wincent's approach, scanning .bash_history.
Ciao,
Dscho
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter error
From: Johannes Schindelin @ 2007-10-22 13:44 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710221337.50730.wielemak@science.uva.nl>
Hi,
On Mon, 22 Oct 2007, Jan Wielemaker wrote:
> On Monday 22 October 2007 13:20, Johannes Schindelin wrote:
>
> > The subdirectory filter does not look kindly upon a history where some
> > commits lack the subdirectory in question. However, this should work:
> >
> > git filter-branch --subdirectory--filter RDF 95807fe01..HEAD
>
> Thanks, but ... hmmm.
>
> $ git filter-branch --subdirectory-filter RDF
> 95807fe01c39d3092e3ac3a98061711323154d77..HEAD
> Rewrite 0a43c802dd60f53d48136a32526a4b2a5f0d43e5 (1/11)fatal: Not a valid
> object name 0a43c802dd60f53d48136a32526a4b2a5f0d43e5:RDF
> Could not initialize the index
I suspect again that this commit does not contain the RDF/ subdirectory.
> This started as a big project with a lot of history in CVS, including
> moved (read deleted and re-created) files. This was moved to SVN and
> from there immediately to GIT. In GIT lots of things have been renamed.
> The RDF directory was created quite recent in the project and things
> from various subdirectories were moved there.
>
> Is there something that might be worth a try or should we go the simple
> way: keeping the old combined repo for later reference and create two
> new ones from fresh files?
It sure sounds pretty tricky. (IOW I'm probably unable to help more...)
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:38 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com>
Hi,
On Mon, 22 Oct 2007, Wincent Colaiuta wrote:
> El 22/10/2007, a las 13:04, Johannes Schindelin escribi?:
>
> > So once again, what operations involving git do people use regularly?
>
> Here are my top ten commands, sorted by the number of times they appear
> in my ~/.bash_history:
Thanks. That's a really good idea. I did the same, and it turns out that
my list was wrong:
68 log
50 fetch
36 show
33 diff
19 grep
19 commit
14 ps (my alias which runs -p status)
10 config
8 rebase
8 push
Everybody who wants to find out the same: this is how I did it:
cat .bash_history |
tr ";" "\\n" |
sed -n "s/^ *git[- ]\([^ ]*\).*$/\1/p" |
sort |
uniq -c |
sort -r -n
One thing that I realised by looking at my list: It probably makes more
sense teaching people about "fetch" in the beginning, teach other parts
about git, and only then "push".
We tend to teach people about "fetch" and "push" at the same time, but
this is not consistent with any workflow.
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Nguyen Thai Ngoc Duy @ 2007-10-22 13:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
On 10/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So once again, what operations involving git do people use regularly?
All operations in my laptop since May:
621 git log
614 git diff
510 git status
378 git grep
203 git checkout
166 git add
159 git commit
106 git fetch
87 git branch
61 git help
55 git am
49 git ls-files
48 git format-patch
46 git show
46 git reset
46 git clone
44 git cherry-pick
42 git merge
36 git apply
26 git cherry
25 git push
25 git describe
24 git rev-list
20 git rebase
18 git pull
17 gitview
16 git shortlog
15 git revert
15 git cat-file
12 git name-rev
11 git update-index
11 git ls-tree
11 git count-objects
10 git tag
9 git send-email
9 git rev-parse
7 git svn
7 git read-tree
6 git repack
6 git fsck
4 git init
4 git clean
3 git rm
3 git gc
2 git submodule
2 git prune
2 git ls
2 gitk
2 git gui
2 git config
1 git mailinfo
1 git lost-found
--
Duy
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: David Symonds @ 2007-10-22 13:33 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Andreas Ericsson, Jakub Narebski,
Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com>
On 22/10/2007, Wincent Colaiuta <win@wincent.com> wrote:
> El 22/10/2007, a las 13:04, Johannes Schindelin escribió:
>
> > So once again, what operations involving git do people use regularly?
>
> Here are my top ten commands, sorted by the number of times they
> appear in my ~/.bash_history:
Sounds like a good idea. Here's mine (my .bash_history is limited to
500 commands, though):
$ cat ~/.bash_history | grep ^git | cut -c5- | cut -d' ' -f1 | sort |
uniq -c | sort -nr | head -10
64 status
37 diff
23 push
13 checkout
12 add
9 log
9 commit
8 rebase
8 branch
5 count-objects
Dave.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Wincent Colaiuta @ 2007-10-22 13:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
El 22/10/2007, a las 13:04, Johannes Schindelin escribió:
> So once again, what operations involving git do people use regularly?
Here are my top ten commands, sorted by the number of times they
appear in my ~/.bash_history:
533 status
342 diff
252 commit
234 add
123 checkout
116 log
106 push
97 config
83 show
83 branch
Not very scientific, but it gives a rough idea of how one Git newbie
(using it for several months) with a very basic workflow uses Git.
Cheers,
Wincent
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-22 13:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, david, git
In-Reply-To: <Pine.LNX.4.64.0710221125350.25221@racer.site>
On Oct 22, 2007, at 12:29 PM, Johannes Schindelin wrote:
>
> On Mon, 22 Oct 2007, Steffen Prohaska wrote:
>
>> .gitattributes is first looked for in the working directory, and
>> if not
>> there, .gitattributes is read from the index.
>
> Of course we could change that to do it the other way round. But this
> would contradict expectations when you edit .gitattributes and then
> checkout single files without having git-add'ed .gitattributes first.
>
> The biggest problem in your setup, however, is not
> if .gitattributes is
> read from the index or the working directory. The biggest problem
> is that
> files are not touched when their contents have not changed.
>
> IOW if you have .gitattributes in the to-be-checked-out branch
> which say
> that README is crlf, and in the current branch it is not, and README's
> _contents_ are identical in both branches, a "git checkout
> <that-other-branch>" will not rewrite README, and consequently not
> change
> the working copy to crlf.
Exactly. The order of reading .gitattributes from the working
directory or the index doesn't matter. The current mechanism
has a more fundamental deficiency.
Changes of.gitattributes can influence how the same content
is checked out to the work tree. If .gitattributes change the
checkout may need to be updated, even if the real content did
not change.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-22 12:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
Johannes Schindelin wrote:
> So once again, what operations involving git do people use regularly?
>
diff
qgit
commit
fetch
rebase
merge
status
push
cherry-pick
grep
bisect
add
show-ref
If I were to suggest any improvements, it'd be to change the semantics
of git-pull to always update the local branches set up to be merged with
the remote tracking branches when they, prior to fetching, pointed to
the same commit, such that when
$ git show-ref master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
refs/heads/master gets set to refs/remotes/origin/master post-fetch.
This would save me from this command sequence, which I currently have to
do for git.
git fetch
git checkout next
git merge spearce/next
git checkout master
git merge spearce/master
git checkout maint
git merge spearce/maint
git checkout pu
git reset --hard spearce/pu
<rinse and repeat for every tracked branch>
git could definitely help here. I want the local branches to be
up-to-date with the remote ones, because I frequently run diffs against
the various branches to see if anything that I should be aware of has
changed, and just as frequently I forget to add that 'origin/' prefix,
which means I *might* be looking at old code.
I usually do that on internal projects, where we have "master", "next",
"testing", and "stable" branches for pretty much every repo. We have 54
git repos. The typing adds up. This is also one of the most frequent
causes of confusion for my (even) less git-savvy co-workers. The
argument usually goes like this:
"Umm... Peter, why did you commit your fix on top of 7 weeks old code?"
"Oh? I did git-pull first, just as you said, so it should have been the
latest, shouldn't it?"
"Well, what branch were you on when you pulled?"
"Err.. does that matter? I didn't have any local modifications on the
branch when I pulled, so it should have just updated it."
What's happened prior to such an argument is usually this:
next or master is inevitably checked out. The user does git-pull to get
up to date. They then change branch and get down to business with
rebasing, merging and editing. When it's time to push, git tells them
"not a strict subset. use git-pull!", and they do, and sometimes it
fails, and I have a hard time explaining why since I really don't see a
reason for *not* updating all "to-merge" branches when they point to the
same commit as their tracking-branch before the pull.
Patch to follow (at some point), although it's likely to make git-pull a
built-in since I have no idea how to maintain coupled lists in shell.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-22 12:26 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Steffen Prohaska, Federico Mena Quintero,
git
In-Reply-To: <471C586A.9030900@op5.se>
On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
[...]
>>>>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>>>
>>>>>> Maybe we could group commands into more categories?
> Similarly, it might be helpful to have help topics the gdb way, like
> "git help patches". It's one of those things that people have come to
> expect from a software tool, so perhaps we should humor them? Given gits
> "every help topic is a man-page" idiom, this shouldn't require any real
> technical effort.
>
> Such topics should probably include
> merge/merges/merging - overview of various ways of putting two lines of
> development back together
> patch/patches - how to create, send and apply
> tags/branches/refs - what they are, why they're good, link to merging
Very good idea. It is definitely something that can be worked on.
By the way, what do you think about "spying" version of git, specially
marked release which gathers statistics of porcelain used, with
frequency of its use, and git-sendstats command added in this release?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Johannes Sixt @ 2007-10-22 12:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071022121106.GA7151@artemis.corp>
Pierre Habouzit schrieb:
> On Mon, Oct 22, 2007 at 11:35:30AM +0000, Johannes Sixt wrote:
>> Pierre Habouzit schrieb:
>>> On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
>>>> Pierre Habouzit schrieb:
>>>>> +say_color () {
>>>>> + [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
>>>>> + shift
>>>>> + echo "* $*"
>>>>> + tput op
^^^^^^^^
I am talking about this line.
>>>>> +}
>> I wanted to point out that if tput is not
>> available, the second invocation will leave "tput: command not found"
>> behind on stderr. Therefore, I proposed to make the definition of
>> say_color() different depending on whether $color is set or not. Then you
>> don't need to test for $color twice inside the function.
>
> Right we can do that. I'll try to rework the patch. and no it
> shouldn't leave tput: command not found as I 2>/dev/null and I think the
> shell doesn't print that in that case. At least my zsh doesn't.
There is no 2>/dev/null. Am I missing something?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Pierre Habouzit @ 2007-10-22 12:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <471C8B02.6080202@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
On Mon, Oct 22, 2007 at 11:35:30AM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
> >>Pierre Habouzit schrieb:
> >>>+say_color () {
> >>>+ [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
> >>>+ shift
> >>>+ echo "* $*"
> >>>+ tput op
> >>>+}
> >>What if tput is not available, like on Windows? How about this (at the
> >>end of the file, so it can obey --no-color):
> > I answered to it already in my first mail: if tput isn't available,
> >the command fails, and $? is non 0. and nocolor is set. Or color isn't
> >set to 't' for your proposal.
>
> I was too terse, sorry. I wanted to point out that if tput is not
> available, the second invocation will leave "tput: command not found"
> behind on stderr. Therefore, I proposed to make the definition of
> say_color() different depending on whether $color is set or not. Then you
> don't need to test for $color twice inside the function.
Right we can do that. I'll try to rework the patch. and no it
shouldn't leave tput: command not found as I 2>/dev/null and I think the
shell doesn't print that in that case. At least my zsh doesn't.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] git-mv submodule failure
From: Yin Ping @ 2007-10-22 11:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211102230.25221@racer.site>
On 10/21/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> No. If you "git mv" a submodule, it makes absolutely no sense to leave
> .gitmodules as is.
>
I can modify the .gitmodule manually since git-submodule mv is not
available. Anyway, I just want a command to rename a submodule easily,
not "mv && git-rm && git-add".
>
--
franky
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter error
From: Jan Wielemaker @ 2007-10-22 11:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710221218150.25221@racer.site>
Dscho,
On Monday 22 October 2007 13:20, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Oct 2007, Jan Wielemaker wrote:
> > Finished a big re-shuffle of a big project, while other developers
> > continued. Worked really well. Thanks guys! But now I have two top
> > directories and I want to create two new repositories, each containing
> > one of these directories (because the one holds copyrighted data and we
> > want the other to become public software). So, I happily run
> >
> > $ git filter-branch --subdirectory-filter RDF HEAD
> >
> > Where RDF is an existing directory. I get:
> >
> > Rewrite 95807fe01c39d3092e3ac3a98061711323154d77 (1/12)fatal: Not a valid
> > object name 95807fe01c39d3092e3ac3a98061711323154d77:RDF
> > Could not initialize the index
>
> I guess that 95807fe01 is the parent of a commit adding the RDF/
> directory.
>
> The subdirectory filter does not look kindly upon a history where some
> commits lack the subdirectory in question. However, this should work:
>
> git filter-branch --subdirectory--filter RDF 95807fe01..HEAD
Thanks, but ... hmmm.
$ git filter-branch --subdirectory-filter RDF
95807fe01c39d3092e3ac3a98061711323154d77..HEAD
Rewrite 0a43c802dd60f53d48136a32526a4b2a5f0d43e5 (1/11)fatal: Not a valid
object name 0a43c802dd60f53d48136a32526a4b2a5f0d43e5:RDF
Could not initialize the index
$ git show 0a43c802dd60f53d48136a32526a4b2a5f0d43e5
commit 0a43c802dd60f53d48136a32526a4b2a5f0d43e5
Merge: 49fa961... 95807fe...
Author: XXX
Date: Thu Oct 18 17:45:26 2007 +0200
Merge branch 'master' of
hildebra@gollem.science.uva.nl:/home/eculture/eculture
Tried 0a43c802dd60f53d48136a32526a4b2a5f0d43e5..HEAD, just to get
another one :-( I guess this will go on a little while :-( Before I
start writing a script that performs this procedure findind a place
where it does work I'd like to share some history with you.
This started as a big project with a lot of history in CVS, including
moved (read deleted and re-created) files. This was moved to SVN and
from there immediately to GIT. In GIT lots of things have been renamed.
The RDF directory was created quite recent in the project and things
from various subdirectories were moved there.
Is there something that might be worth a try or should we go the simple
way: keeping the old combined repo for later reference and create two
new ones from fresh files?
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Johannes Sixt @ 2007-10-22 11:35 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Sixt, Shawn O. Pearce, git
In-Reply-To: <20071022112401.GE32763@artemis.corp>
Pierre Habouzit schrieb:
> On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
>> Pierre Habouzit schrieb:
>>> +say_color () {
>>> + [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
>>> + shift
>>> + echo "* $*"
>>> + tput op
>>> +}
>> What if tput is not available, like on Windows? How about this (at the
>> end of the file, so it can obey --no-color):
>
> I answered to it already in my first mail: if tput isn't available,
> the command fails, and $? is non 0. and nocolor is set. Or color isn't
> set to 't' for your proposal.
I was too terse, sorry. I wanted to point out that if tput is not available,
the second invocation will leave "tput: command not found" behind on stderr.
Therefore, I proposed to make the definition of say_color() different
depending on whether $color is set or not. Then you don't need to test for
$color twice inside the function.
-- Hannes
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Johannes Schindelin @ 2007-10-22 11:32 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Petr Baudis, git
In-Reply-To: <200710221044.24191.wielemak@science.uva.nl>
Hi,
On Mon, 22 Oct 2007, Jan Wielemaker wrote:
> Thanks for the replies. I think I can live with something like this
>
> <work, in the middle of something>
> $ git checkout -b home
> $ git commit
> $ git checkout master
> <arriving at home>
> $ git jan@work:repo fetch home:home (using ssh)
You probably meant "git fetch jan@work:repo home:home".
> $ git checkout home
> <continue editing>
> $ git commit --amend
> $ git checkout master
> $ git merge home
> $ git -d home
> $ git commit
> $ git push
> <arriving at work>
> $ git -d home
> $ git pull
>
> Its still a bit many commands and you have to be aware what you are
> doing for quite a while, but it does provide one single clean commit
> message, doesn't change the shared repo until all is finished and allows
> to abandon all work without leaving traces.
>
> Personally I'd be more happy with
>
> <work, in the middle of something>
> $ git stash
> <arriving at home>
> $ git stash fetch jan@work{0} (well, some sensible syntax)
> $ git stash apply
> <continue editing>
> $ git commit
> $ git push
> <arriving at work>
> $ git pull
Happily, that is already possible: However, instead of
git stash fetch jan@work{0}
you should say
git fetch jan@work stash:stash
This will only fetch the last stash, but that is what you wanted anyway,
right?
Ciao,
Dscho
P.S.: Since you top-posted, I just ignored the mail you quoted, assuming
that it was not relevant to your mail.
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Pierre Habouzit @ 2007-10-22 11:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <471C6510.8010300@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> >---
> >Maybe this is just me, but I don't find the output of the test-suite
> >easy to watch while scrolling. This puts some colors in proper places.
> > * end-test summaries are in green or red depending on the sucess of
> > the tests.
> > * errors are in red.
> > * skipped tests and other things that tests `say` are in brown (now
> > you can _see_ that your testsuite skips some tests on purpose, I
> > only noticed recently that I missed part of the environment for
> > proper testing).
> >I'm not 100% sure the test to see if terminal supports color is correct,
> >and
> >people using emacs shell buffer or alike tools may have better ideas on
> >how to
> >make it.
> >and yes, I know that it "depends" upon tput, but if tput isn't
> >available, the
> > [ "x$TERM" != "xdumb" ] && tput hpa 60 >/dev/null 2>&1 && tput setaf
> >1 >/dev/null 2>&1
> >expression will fail, and color will be disabled.
> > t/test-lib.sh | 32 ++++++++++++++++++++++----------
> > 1 files changed, 22 insertions(+), 10 deletions(-)
> >diff --git a/t/test-lib.sh b/t/test-lib.sh
> >index cc1253c..c6521c0 100644
> >--- a/t/test-lib.sh
> >+++ b/t/test-lib.sh
> >@@ -59,14 +59,24 @@ esac
> > # '
> > # . ./test-lib.sh
> > +[ "x$TERM" != "xdumb" ] && tput hpa 60 >/dev/null 2>&1 && tput setaf 1
> >>/dev/null 2>&1
> >+nocolor=$?
>
> test "x$TERM" != "xdumb" &&
> tput hpa 60 >/dev/null 2>&1 &&
> tput setaf 1 >/dev/null 2>&1 &&
> color=t
>
> BTW, doesn't tput fail if stdout/stderr is not a terminal, like above?
>
> >+
> >+say_color () {
> >+ [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
> >+ shift
> >+ echo "* $*"
> >+ tput op
> >+}
>
> What if tput is not available, like on Windows? How about this (at the
> end of the file, so it can obey --no-color):
I answered to it already in my first mail: if tput isn't available,
the command fails, and $? is non 0. and nocolor is set. Or color isn't
set to 't' for your proposal.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter error
From: Johannes Schindelin @ 2007-10-22 11:20 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710221227.13279.wielemak@science.uva.nl>
Hi,
On Mon, 22 Oct 2007, Jan Wielemaker wrote:
> Finished a big re-shuffle of a big project, while other developers
> continued. Worked really well. Thanks guys! But now I have two top
> directories and I want to create two new repositories, each containing
> one of these directories (because the one holds copyrighted data and we
> want the other to become public software). So, I happily run
>
> $ git filter-branch --subdirectory-filter RDF HEAD
>
> Where RDF is an existing directory. I get:
>
> Rewrite 95807fe01c39d3092e3ac3a98061711323154d77 (1/12)fatal: Not a valid
> object name 95807fe01c39d3092e3ac3a98061711323154d77:RDF
> Could not initialize the index
I guess that 95807fe01 is the parent of a commit adding the RDF/
directory.
The subdirectory filter does not look kindly upon a history where some
commits lack the subdirectory in question. However, this should work:
git filter-branch --subdirectory--filter RDF 95807fe01..HEAD
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Let users override name of per-directory ignore file
From: Andreas Ericsson @ 2007-10-22 11:18 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, spearce
In-Reply-To: <20071022105029.GB31862@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-10-15 14:09:32 +0200, Andreas Ericsson wrote:
>
>> When collaborating with projects managed by some other scm, it often
>> makes sense to have git read that other scm's ignore-files. This
>> patch lets git do just that, if the user only tells it the name of
>> the per-directory ignore file by specifying the newly introduced git
>> config option 'core.ignorefile'.
>
>> + For example, setting core.ignorefile to .svnignore in
>> + repos where one interacts with the upstream project repo
>> + using gitlink:git-svn[1] will make a both SVN users and
>> + your own repo ignore the same files.
>
>> + The name of the `.gitignore` file can be changed by setting
>> + the configuration variable 'core.ignorefile'. This is useful
>> + when using git for projects where upstream is using some other
>> + SCM. For example, setting 'core.ignorefile' to `.cvsignore`
>> + will make git ignore the same files CVS would.
>
> I agree with what you're trying to do, but you're ignoring the fact
> that Subversion's ignore patterns (and possibly cvs's too -- I haven't
> checked) are not recursive, while the patterns in .gitignore are
> recursive per default. So using ignore patterns directly from
> Subversion ignores more files under git than the same patterns did
> under Subversion.
>
Yes, I just got bitten by this. The top-level .cvsignore file ignores
Makefile (since it's generated from ./configure), but Makefile exists in
several subdirectories where it's *not* generated, but adding !Makefile
to all those places doesn't sit too well with some of the project
maintainers, and cvs doesn't grok /Makefile to mean "toplevel Makefile"
(and it shouldn't since it has no notion of recursive ignores).
> One possible way to solve that would be to optionally have
> non-recursive per-directory ignore files. I haven't looked at how this
> is implemented, though, so I don't know if it's a good suggestion or
> not.
>
I'll have a look at it. Thanks for the review.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-format-patch: Don't number patches when there's only one
From: Andreas Ericsson @ 2007-10-22 11:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <Pine.LNX.4.64.0710221119300.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> [PATCH 1/1] looks a bit silly, and automagically handling this in
>>>> git-format-patch makes some scripting around it a lot more pleasant.
>>> I think you should not use "-n" if you do not want to have the
>>> numbers.
>> This stems from creating scripts around it where I only want to see the
>> numbers if there is more than a single patch. Currently I can't do that
>> without running git-format-patch twice or re-implementing the revision
>> parsing machinery to count revisions prior to passing arguments to
>> format-patch.
>
> Why not have something as simple as
>
> numbered=
> test $(git rev-list $options | wc -l) -gt 1 && numbered=-n
>
Because 23498~12 != 23498~12..HEAD to git rev-list, but it is to
git-format-patch, meaning I'll have to duplicate the logic in every
script that's supposed to use it or risk introducing a third way of
specifying a list of revisions.
> [...]
>
> git format-patch $numbered $options
>
> At the moment, the semantics of "--numbered" is really clear and precise.
> And I really like that. It makes for less surprises.
>
Semantics could be equally clear for --numbered-if-multiple.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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