* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Nicolas Pitre @ 2007-06-13 17:54 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <477C424C-009F-46BF-85D4-A0D777FE3CEC@mimvista.com>
On Wed, 13 Jun 2007, David Watson wrote:
> Because git-commit -a is nice to use, especially if I really want to check in
> all the files, *except a particular set that is always the same*. Having to
> specify the files every time gets old pretty quick.
>
> If I could do this:
>
> $ git-commit -a --exclude=somefile
>
> that would be very useful. Or even, if I could set a file in my .git folder
> that would be an exclude list, then I could run something like
>
> $ git-commit -a --use-excludes
>
> I suppose the answer is to create the patch myself.
Well, before that I'd suggest you have a look at the git-add man page,
especially the -u flag and the core.excludesfile config option.
Nicolas
^ permalink raw reply
* Re: pull into dirty working tree
From: Michael Dressel @ 2007-06-13 17:31 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18032.3836.710438.73912@lisa.zopyra.com>
Hi,
but even if they just play with the code. Why not always commit?
As long as they don't push nobody else will be affected.
Even if you play with the code it's useful to go back to earlier
versions. Why would you not want to benefit from this possibility?
So this would really only be two commands the commit and the pull command.
I hope I didn't miss your point completely.
Cheers
Michael
On Wed, 13 Jun 2007, Bill Lear wrote:
> On Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes:
> >Hi,
> >
> >why don't they just do a simple
> >git commit -a
> >of their work before pulling?
>
> Because they are basically playing with some code and don't want to
> commit it.
>
> >That's different to cvs! Committing only affects the cloned repository.
>
> Yup, we realize that.
>
> >I think one of the biggest advantages of git is the concept of everyone
> >working on a clone. So developers are not prevented from actually using
> >revision control just because they are afraid of disturbing others. They
> >don't until they e.g. push!
>
> Right, but they just want updates to their working tree, as they could
> do under CVS, without issuing five (or even one) other commands.
>
>
> Bill
>
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Nicolas Pitre @ 2007-06-13 17:21 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com>
On Wed, 13 Jun 2007, David Watson wrote:
> I've got a problem, or maybe annoyance is more the proper term, that I haven't
> seen solved by any SCM system (at least not to my knowledge). Basically, I may
> make some changes, e.g. to a Makefile or somesuch, that I want to ignore when
> looking at what's changed from the repository. The only problem is, the file
> I've modified is already under version control, so .gitignore doesn't do
> anything.
>
> Now, I can commit it, so it will stop bugging me, but then when I push out it
> will include that change, unless I back it out. This is a change that I don't
> want propagated anywhere else, because it's specific to my machine or
> development sandbox.
>
> Is there any way to do this? I'd really love to use git-commit -a in this
> situation, and I could hack up a script to undo my change, run git-commit -a,
> and reapply the change, but makes me a bit squirmy. If I could put something
> in a .git config file to say "commit 237ab should not be propagated under any
> circumstances", that would be fantastic.
Why don't you just use git-commit _without_ -a ?
The whole purpose behind not specifying -a with git-commit is exactly
for your usage example.
Nicolas
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Junio C Hamano @ 2007-06-13 17:17 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Johannes Schindelin, Marco Costalba, Shawn O. Pearce,
Linus Torvalds, Git Mailing List
In-Reply-To: <200706131854.59605.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Wednesday 13 June 2007, Josef Weidendorfer wrote:
>> While without "-z", log_tree_diff immediatly returns
>> because "opt->diff" is 0, in the case of "-z",
>> the tree differences are fully done even not used at all ?!
>
> I wished git-gui and gitk would be better integrated for
> history/blame browsing; I also missed a text search functionality
> in the blame view of git-gui.
>
> Neverless...
>
> opt->diff is set to 1 in setup_revisions() whenever
> diff_opt_parse() parses an option. And "-z" is
> parsed in diff_opt_parse().
>
> In cd2bdc, Linus write in the commit log
>
> - make setup_revision set a flag (revs->diff) if the diff-related
> arguments were used. This allows "git log" to decide whether it wants
> to show diffs or not.
>
> So why is "-z" regarded as tree-diff related, leading to calculating diffs?
Because of the thinko in that commit. He obviously meant
things like --stat, -p and its friends.
^ permalink raw reply
* Re: pull into dirty working tree
From: Junio C Hamano @ 2007-06-13 17:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, git
In-Reply-To: <Pine.LNX.4.64.0706131559210.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The other thing, if you have to, is to put all dirty changes into the
> index before pull. Something like "git add $(git ls-files --modified)".
> You can even make that a global alias for your users. Although IIRC it
> does not work if the merge changes the same files as your dirty work tree
> touches, but I could very well be wrong there.
I do not think that would change the issue in general, as the
index needs to be clean (wrt HEAD) during a conflicting merge.
Incidentally, I was planning to start a "stash dirty state and
later reapply on a different commit" soon (if I survive an event
planned tomorrow, that is ;-).
When you are in the middle of something (and when you are not in
the middle of a merge), you have two states you care about.
What is in the index, and what is in the working tree.
Conceptually, even though you do _not_ have commits for these
two extra states, your "history" would look like this:
o <- working tree state = W
/
o <- index state = I
/
-------o <- HEAD
A dirty merge (whether it is done as "git checkout $another",
"git merge $commit", or "git pull $somebodyelse") is to first
stash away I and W, perform the merge proper to advance HEAD,
and after all that is done, recreate the index and working tree
state on top of the updated HEAD, to arrive at this:
o --> * <- new working tree state = W'
/ /
o --> * <- new index state = I'
/ /
-------o-------* <- merge = new HEAD
old HEAD ^ /
/
--------o---o <- other history
This can be internally done as four steps:
* stash the dirty states (save I and W)
- record I by "git commit" (no parameters to commit the index).
- record W by "git add . && git commit -a".
- remember HEAD as $STASH.
* match the working tree and the index to original HEAD by
"reset HEAD^ && reset --hard HEAD". The first --mixed reset
is to forget about new files added with "git add .", so that
the second reset will not remove them from the working tree.
* perform a merge in the resulting clean tree
* unstash the dirty states
- I' is the three-way merge between $STASH~1 and the new HEAD
using $STASH~2 as the common ancestor.
- W' is the three-way merge between $STASH and I' using
$STASH~1 as the common ancestor.
Unstashing operation can potentially require two merge conflict
resolutions. As we _care_ about distinction between the index
state and the working tree state, this is unavoidable.
Side note: as an implementation, it is a possibility not to
record I and record only W as the direct child of the HEAD
when stashing. Unstashing would update only the working
tree (i.e. after unstashing, the index and the HEAD exactly
matches). But it risks "forgetting" newly added files and I
would say it is unacceptable for that reason, even if we
declare that this feature is only for non-git people.
Combined with the potential conflict resolution for the merge
proper, you have to resolve up to three merges in a row. One
conflict resolution is something even CVS users must accept
anyway, so we are talking about up to two _extra_ conflict
resolutions here.
^ permalink raw reply
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Joakim Tjernlund @ 2007-06-13 17:13 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <20070613092328.GA30318@muzzle>
On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:
> dcommit will still rewrite the HEAD commit and the history of the first
> parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
>
> However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
> preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN
> with dcommit. Commits written to SVN will still not have any merge
> information besides anything in the commit message.
>
> Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
> for explanations, feedback, examples and test case.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> This is a better patch that replaces the previous one.
>
> Junio:
> This one is a big change and should probably sit in pu or next
> for a bit. Double-checking the logic in linearize_history()
> would be greatly appreciated, too.
>
> I don't think there are any regressions for the
> already-linear-history case besides slightly reduced performance for
> new calls to cat-file.
>
> Joakim/Steven:
> Any further testing and test cases would be appreciated. Be very
> careful with real-world repositories, and run dcommit with the
> '-n' flag before actually committing to verify the diffs are sane.
>
> Thanks
>
Did a little testing and so far it looks good :)
Sidenote:
Doing this
git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo
git-svn fetch --quiet
makes git svn fetch stop for rather long periods in do_update:
Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2
Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8
Following parent with do_update
Successfully followed parent
Is it possible to speed up do_update?
Lastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,
can I attach the svn tree to git u-boot tree without using a graft?
I want to be able to recreate my own git repo by cloning the orginal u-boot
repo and the svn repo.
Jocke
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Johannes Schindelin @ 2007-06-13 17:05 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <200706131854.59605.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 13 Jun 2007, Josef Weidendorfer wrote:
> opt->diff is set to 1 in setup_revisions() whenever
> diff_opt_parse() parses an option. And "-z" is
> parsed in diff_opt_parse().
>
> In cd2bdc, Linus write in the commit log
>
> - make setup_revision set a flag (revs->diff) if the diff-related
> arguments were used. This allows "git log" to decide whether it wants
> to show diffs or not.
>
> So why is "-z" regarded as tree-diff related, leading to calculating diffs?
Because it changes the behaviour of a diff. As far as I can tell, the line
termination does not have any effect on any output _except_ the diff
output.
So, I should have realized earlier that "git-log -z" _without_ anything in
the way of "-p", "--stat" or friends does not make sense at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-13 16:59 UTC (permalink / raw)
To: Matthias Lederhofer, Junio C Hamano; +Cc: git
In-Reply-To: <20070613163136.GA28101@moooo.ath.cx>
On 6/13/07, Matthias Lederhofer <matled@gmx.net> wrote:
> Lars Hjemli <hjemli@gmail.com> wrote:
> > Could you please try one or both of the following escape-sequences?
> >
> > \.gitmodules
> > #.gitmodules#
>
> #.gitmodules# seems to produce a good xml file, html is fine too. But
> the conversion from xml to a manpage seems to be broken:
>
> $ xmlto -m callouts.xsl man gitmodules.xml
>
> transforms
>
> <refsynopsisdiv>
> <simpara>.gitmodules</simpara>
>
> </refsynopsisdiv>
>
> to
>
> .SH "SYNOPSIS"
> .gitmodules
>
> ".gitmodules" is not shown in the manpage and vim highlights the ".gi"
> just like ".SH" in a special color. Perhaps we should just highlight
> .gitmodules like commands with single quotes. This solves both
> problems :)
>
Ok, thanks for trying to clean up my mess. I guess there's a good
reason why Junios examples drop the leading dot (cat
/usr/share/man/man1/git-submodule.1 was an eyeopener for me right now
;-)
--
larsh
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Josef Weidendorfer @ 2007-06-13 16:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <200706131827.08163.Josef.Weidendorfer@gmx.de>
On Wednesday 13 June 2007, Josef Weidendorfer wrote:
> While without "-z", log_tree_diff immediatly returns
> because "opt->diff" is 0, in the case of "-z",
> the tree differences are fully done even not used at all ?!
I wished git-gui and gitk would be better integrated for
history/blame browsing; I also missed a text search functionality
in the blame view of git-gui.
Neverless...
opt->diff is set to 1 in setup_revisions() whenever
diff_opt_parse() parses an option. And "-z" is
parsed in diff_opt_parse().
In cd2bdc, Linus write in the commit log
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
So why is "-z" regarded as tree-diff related, leading to calculating diffs?
Josef
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Johannes Schindelin @ 2007-06-13 16:50 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <200706131827.08163.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 13 Jun 2007, Josef Weidendorfer wrote:
> On Wednesday 13 June 2007, Johannes Schindelin wrote:
> > ~1.4s log _with_ --pretty=raw
> > ~3.5s log _with_ --pretty=raw _and_ -z (!)
>
> That happens on linux, too.
>
> I am not really familiar with that code, but comparision
> of the call graphs of "git log" vs. "git log -z", as
> produced by callgrind (shameless plug) and visualized
> by kcachegrind (again, another shameless plug) shows
> that the difference happens in log_tree_diff, called
> >from log_tree_commit.
That's a cool trick!
And indeed it is:
This code in revision.c is responsible:
1181 opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
1182 if (opts > 0) {
1183 revs->diff = 1;
1184 i += opts - 1;
1185 continue;
1186 }
Now, to tell which diff options actually need revs->diff to be set to 1,
that is the question.
Ciao,
Dscho
^ permalink raw reply
* Re: How to stage a tree with all changes?
From: Matthieu Moy @ 2007-06-13 16:47 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861wgf964g.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Suppose I have a number of changes in a tree: additions, deletions,
> renames and so on.
At commit time, a rename is just an add+delete for git. It'll
investigate renames with heuristics later, when needed.
> How do I stage and commit all of that?
Well, what I usually do is
$ git status
(nicer with
[status]
color = auto
in ~/.gitconfig)
and then "confirm" one by one the things I actually want to commit.
> git-commit -a
>
> omits new files.
>
> git-add .
> git-commit -a
The -a is not necessary if you just did "git add .".
> seemingly overlooks deletions.
In most cases, you'd have deleted the files with "rm", and you could
have told git at that time, using "git rm" instead. Otherwise,
$ git-ls-files -z | git-update-index --remove -z --stdin
will remove deleted files from the index after the fact. But I don't
know any porcelain command to do that. Perhaps a "git rm -u" could be
a nice dual for "git add -u"?
--
Matthieu
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Johannes Schindelin @ 2007-06-13 16:40 UTC (permalink / raw)
To: Marco Costalba
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Git Mailing List
In-Reply-To: <e5bfff550706130918k47b2d58dq73216732c90f65ce@mail.gmail.com>
Hi,
On Wed, 13 Jun 2007, Marco Costalba wrote:
> Something slows down terribly git-log under Windows when -z option is
> given, expecially on cygwin.
>
>
> Some idea, sir?
No. Not yet.
Ciao,
Dscho
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Pierre Habouzit @ 2007-06-13 16:33 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
On Wed, Jun 13, 2007 at 11:47:33AM -0400, David Watson wrote:
> I've got a problem, or maybe annoyance is more the proper term, that I
> haven't seen solved by any SCM system (at least not to my knowledge).
> Basically, I may make some changes, e.g. to a Makefile or somesuch, that
> I want to ignore when looking at what's changed from the repository. The
> only problem is, the file I've modified is already under version control,
> so .gitignore doesn't do anything.
>
> Now, I can commit it, so it will stop bugging me, but then when I push
> out it will include that change, unless I back it out. This is a change
> that I don't want propagated anywhere else, because it's specific to my
> machine or development sandbox.
>
> Is there any way to do this? I'd really love to use git-commit -a in this
> situation, and I could hack up a script to undo my change, run git-commit
> -a, and reapply the change, but makes me a bit squirmy. If I could put
> something in a .git config file to say "commit 237ab should not be
> propagated under any circumstances", that would be fantastic.
please read the thread [ pull into dirty working tree ] that is just
about this, and like errr 2 threads before yours.
--
·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: [PATCH 2/3] Add gitmodules(5)
From: Matthias Lederhofer @ 2007-06-13 16:31 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580706130913j2d3095d1n649145ff540d1bec@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> Could you please try one or both of the following escape-sequences?
>
> \.gitmodules
> #.gitmodules#
#.gitmodules# seems to produce a good xml file, html is fine too. But
the conversion from xml to a manpage seems to be broken:
$ xmlto -m callouts.xsl man gitmodules.xml
transforms
<refsynopsisdiv>
<simpara>.gitmodules</simpara>
</refsynopsisdiv>
to
.SH "SYNOPSIS"
.gitmodules
".gitmodules" is not shown in the manpage and vim highlights the ".gi"
just like ".SH" in a special color. Perhaps we should just highlight
.gitmodules like commands with single quotes. This solves both
problems :)
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 16:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0706131702020.4059@racer.site>
On Wednesday, June 13, 2007 at 17:07:20 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Wed, 13 Jun 2007, Bill Lear wrote:
>
>> I wonder, also, if there could be a way to alert users that their
>> working tree is dirty before all the git pull blather comes out, scaring
>> their poor little souls?
>
>Well, it's their fault, isn't it?
Yes, it is. But that's no reason not to try to produce a nicer warning.
>> fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.
>
>Sorry, this is the first time Git can realize that the dirty working
>directory conflicts with the changes about to be applied.
Ah, this makes sense. It has to do all the other stuff first and only
when it comes across one that won't "fit" does it complain. This makes
more sense now...
Bill
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Josef Weidendorfer @ 2007-06-13 16:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706131553390.4059@racer.site>
On Wednesday 13 June 2007, Johannes Schindelin wrote:
> ~1.4s log _with_ --pretty=raw
> ~3.5s log _with_ --pretty=raw _and_ -z (!)
That happens on linux, too.
I am not really familiar with that code, but comparision
of the call graphs of "git log" vs. "git log -z", as
produced by callgrind (shameless plug) and visualized
by kcachegrind (again, another shameless plug) shows
that the difference happens in log_tree_diff, called
from log_tree_commit.
While without "-z", log_tree_diff immediatly returns
because "opt->diff" is 0, in the case of "-z",
the tree differences are fully done even not used at all ?!
The result is that "log_tree_commit" executes (inclusive
callees) 340 million instructions without "-z", while
it runs 2300 million instructions in the "-z" case.
Josef
^ permalink raw reply
* How to stage a tree with all changes?
From: David Kastrup @ 2007-06-13 16:22 UTC (permalink / raw)
To: git
Suppose I have a number of changes in a tree: additions, deletions,
renames and so on.
How do I stage and commit all of that?
git-commit -a
omits new files.
git-add .
git-commit -a
seemingly overlooks deletions.
What am I overlooking? This should be simple, shouldn't it?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Junio C Hamano @ 2007-06-13 16:20 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Lars Hjemli, git
In-Reply-To: <20070613153611.GA11852@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Lars Hjemli <hjemli@gmail.com> wrote:
>> +SYNOPSIS
>> +--------
>> +.gitmodules
>
> My asciidoc (7.1.2 and 8.2.1) generates an empty refsynopsisdiv from
> this. xmlto refuses to convert this into anything else:
> ...
> This breaks the build process for the documentation. I could not find
> out how to fix this. Probably just needs the right quoting for the
> dot at the beginning of the line.
Sorry, I should have caught this much earlier, as already knew
about this issue when I did gitattributes(5).
As it seems to be customary not to even say 'dot' at the
beginning for man(5) section (existing examples I found are
netrc, postgresrc, procmailrc, ...), I think the best fix is
just to do s/\.gitmodules/gitmodules/ there.
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Marco Costalba @ 2007-06-13 16:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706131553390.4059@racer.site>
On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> I just tested on cygwin. The funny thing is, I never get anything like 8
> seconds (this is on git.git itself).
>
> For me it is
>
> ~1.0s rev-list _without_ --pretty=raw
> ~1.6s rev-list _with_ --pretty=raw
> ~1.4s log _with_ --pretty=raw
> ~3.5s log _with_ --pretty=raw _and_ -z (!)
>
> So, your delay could stem from -z doing weird things.
>
Yes. I can confirm that without -z the speed is more or less the same
of git-rev-list.
I've tested with cygwin installation of git *.exe files.
>
> Draw your conclusions, gentlemen.
>
Something slows down terribly git-log under Windows when -z option is
given, expecially on cygwin.
Some idea, sir?
Thanks
Marco
P.S: I really would need a zero terminated record for parsing reasons,
and git-rev-list prints a zero terminated output too with --header
option and it works correctly.
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-13 16:13 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070613153611.GA11852@moooo.ath.cx>
On 6/13/07, Matthias Lederhofer <matled@gmx.net> wrote:
> Lars Hjemli <hjemli@gmail.com> wrote:
> > +SYNOPSIS
> > +--------
> > +.gitmodules
>
> My asciidoc (7.1.2 and 8.2.1) generates an empty refsynopsisdiv from
> this. xmlto refuses to convert this into anything else:
Sorry about that, I don't have a working asciidoc :-(
But looking through the latest asciidoc-doc suggests that .gitmodules
is treated like a blocktitle:
http://www.methods.co.nz/asciidoc/userguide.html#toc33
Could you please try one or both of the following escape-sequences?
\.gitmodules
#.gitmodules#
Thanks
--
larsh
^ permalink raw reply
* Re: pull into dirty working tree
From: Johannes Schindelin @ 2007-06-13 16:07 UTC (permalink / raw)
To: Bill Lear; +Cc: Andy Parkins, git
In-Reply-To: <18032.5016.716192.939675@lisa.zopyra.com>
Hi,
On Wed, 13 Jun 2007, Bill Lear wrote:
> I wonder, also, if there could be a way to alert users that their
> working tree is dirty before all the git pull blather comes out, scaring
> their poor little souls?
Well, it's their fault, isn't it?
> So, instead of this:
>
> % git pull
> remote: Generating pack...
> remote: Done counting 122 objects.
> remote: Result has 90 objects.
> remote: Deltifying 90 objects.
> remote: 100% (90/90) done
> Unpacking 90 objects
> remote: Total 90 (delta 59), reused 41 (delta 10)
> 100% (90/90) done
> * refs/remotes/origin/master: fast forward to branch 'master' of
> git://source/sc
> old..new: 171b65f..0be3472
> * refs/remotes/origin/v1.0: fast forward to branch 'v1.0' of
> git://source/sc
> old..new: a9de9dd..efa3a73
> Updating 717d9f6..0be3472
> src/fs/testsuite/fs.tst/gettest: needs update
> src/nl/EocCompiler.cc: needs update
> src/nl/EocCompiler.hh: needs update
> src/nl/Nl.cc: needs update
> fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.
Sorry, this is the first time Git can realize that the dirty working
directory conflicts with the changes about to be applied.
For example, I run "git pull" very often with a modified Makefile. If the
merge would not touch the Makefile, it would succeed. No need to do
anything fancy.
If you do have to shut the (otherwise useful) messages up, you can always
have an alias (using the advanced technique illustrated in another post in
this thread).
> % git pull
> Sorry, I can't pull, as you have a dirty working tree. Please commit
> your changes or move your files before you pull. These are the
> files that are preventing this:
>
> src/fs/testsuite/fs.tst/gettest
> src/nl/EocCompiler.cc
> src/nl/EocCompiler.hh
> src/nl/Nl.cc
As far as I can see, gettest is not responsible, so this would be wrong.
Ciao,
Dscho
^ permalink raw reply
* Any way to ignore a change to a tracked file when committing/merging?
From: David Watson @ 2007-06-13 15:47 UTC (permalink / raw)
To: git
I've got a problem, or maybe annoyance is more the proper term, that
I haven't seen solved by any SCM system (at least not to my
knowledge). Basically, I may make some changes, e.g. to a Makefile or
somesuch, that I want to ignore when looking at what's changed from
the repository. The only problem is, the file I've modified is
already under version control, so .gitignore doesn't do anything.
Now, I can commit it, so it will stop bugging me, but then when I
push out it will include that change, unless I back it out. This is a
change that I don't want propagated anywhere else, because it's
specific to my machine or development sandbox.
Is there any way to do this? I'd really love to use git-commit -a in
this situation, and I could hack up a script to undo my change, run
git-commit -a, and reapply the change, but makes me a bit squirmy. If
I could put something in a .git config file to say "commit 237ab
should not be propagated under any circumstances", that would be
fantastic.
-Dave Watson
^ permalink raw reply
* Re: pull into dirty working tree
From: Johannes Schindelin @ 2007-06-13 15:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Bill Lear
In-Reply-To: <200706131640.22588.andyparkins@gmail.com>
Hi,
On Wed, 13 Jun 2007, Andy Parkins wrote:
> On Wednesday 2007 June 13, Johannes Schindelin wrote:
>
> > The other thing, if you have to, is to put all dirty changes into the
> > index before pull. Something like "git add $(git ls-files --modified)".
>
> Or the shiny new
>
> git add -u
>
> which works a treat :-)
Yeah, completely forgot about that.
Another idea just hit me: you could add this to your "[alias]" section:
stash = !git add -u && \
tree=$(git-write-tree) && \
commit=$(echo stash $(date) | \
git-commit-tree $tree -p HEAD) && \
git-update-ref refs/heads/stash $commit && \
git-reset --hard
up = !git stash && git pull && git cherry-pick -n stash
Or something like that (untested!). Then, your users could use "git up" to
pull from origin, and reapply their changes on top, without committing.
This assumes that your users only have the remote "origin", but given
their obvious "objections" to Git concepts, I think they do.
Ciao,
Dscho
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 15:56 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin
In-Reply-To: <200706131640.22588.andyparkins@gmail.com>
On Wednesday, June 13, 2007 at 16:40:18 (+0100) Andy Parkins writes:
>On Wednesday 2007 June 13, Johannes Schindelin wrote:
>
>> The other thing, if you have to, is to put all dirty changes into the
>> index before pull. Something like "git add $(git ls-files --modified)".
>
>Or the shiny new
>
> git add -u
>
>which works a treat :-)
Better.
I wonder, also, if there could be a way to alert users that their
working tree is dirty before all the git pull blather comes out,
scaring their poor little souls? So, instead of this:
% git pull
remote: Generating pack...
remote: Done counting 122 objects.
remote: Result has 90 objects.
remote: Deltifying 90 objects.
remote: 100% (90/90) done
Unpacking 90 objects
remote: Total 90 (delta 59), reused 41 (delta 10)
100% (90/90) done
* refs/remotes/origin/master: fast forward to branch 'master' of
git://source/sc
old..new: 171b65f..0be3472
* refs/remotes/origin/v1.0: fast forward to branch 'v1.0' of
git://source/sc
old..new: a9de9dd..efa3a73
Updating 717d9f6..0be3472
src/fs/testsuite/fs.tst/gettest: needs update
src/nl/EocCompiler.cc: needs update
src/nl/EocCompiler.hh: needs update
src/nl/Nl.cc: needs update
fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge.
we could have:
% git pull
Sorry, I can't pull, as you have a dirty working tree. Please commit
your changes or move your files before you pull. These are the
files that are preventing this:
src/fs/testsuite/fs.tst/gettest
src/nl/EocCompiler.cc
src/nl/EocCompiler.hh
src/nl/Nl.cc
Bill
^ permalink raw reply
* Re: [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Josef Sipek @ 2007-06-13 15:54 UTC (permalink / raw)
To: Benjamin Sergeant; +Cc: Pierre Habouzit, git
In-Reply-To: <1621f9fa0706130810n17bc3f67h1c539d75b3aed4ed@mail.gmail.com>
On Wed, Jun 13, 2007 at 08:10:36AM -0700, Benjamin Sergeant wrote:
> For the shebang:
> #!/usr/bin/env bash
> should works well and should work on non-linux boxes that did not
> added a link in /bin/bash.
Ideally, the best thing to do is to change guilt to use /bin/sh. Right now,
there are a number of bash-isms that are used. And if a system doesn't have
/bin/sh, it doesn't deserve to run any useful software ;)
Patches are welcomed ;)
Josef "Jeff" Sipek.
--
Reality is merely an illusion, albeit a very persistent one.
- Albert Einstein
^ 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