* Re: [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int
From: Shawn O. Pearce @ 2008-12-17 22:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229553172-2038-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> If not dates past 2038 will be parsed the wrong way when
> parsed into a RevCommit or RevTag object.
Uhm, sure.
But there's also the commitTime field in RevCommit, its used to
sort commits during walking. In 2038 that will also overflow.
Also, if you search the code for '2038' you'll find a remark
about the year 2038 in DirCacheEntry.smudgeRacilyClean. Last
I looked at the git sources I think this field in the index is
treated as a signed time_t so we can't set the high bits and
extend it out another 60+ years.
Honestly, I'm not sure this patch is worth the code duplication
without fixing our other two known 2038 problem spots... and
I really don't want to make RevCommit.commitTime into a long,
as that will bloat out the object allocations and slow down the
comparsion on 32 bit JVMs. Right now at the end of 2008 the memory
isn't as readily available and there's still a lot of 32 bit JVMs.
Another 10 years we'll probably be looking at 256 bit wide registers
being very common, and 1 PB of core memory, and extending these
fields out to a long will be trivial. And we'll still have 20
years to make the transition.
I'd rather just tag the fields with "2038" so we can search for
them in the future. Like say this:
--8<--
Mark the other two locations that break in the year 2038
When the 32 bit timestamp rolls over in 2038 these spots in JGit
will break, unless we upgrade them to use a 64 bit long before then.
For now its too time and memory intensive to use a full long here,
but in another 10 years we should have enough computing power that
this is a moot point and we can upgrade the code paths marked with
by 'git grep 2038'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/revwalk/RevCommit.java | 2 ++
.../src/org/spearce/jgit/util/RawParseUtils.java | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
index 9d30018..bcfd8c4 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
@@ -129,6 +129,8 @@ else if (nParents == 1) {
ptr = RawParseUtils.committer(raw, ptr);
if (ptr > 0) {
ptr = RawParseUtils.nextLF(raw, ptr, '>');
+
+ // In 2038 commitTime will overflow unless it is changed to long.
commitTime = RawParseUtils.parseBase10(raw, ptr, null);
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index 55a3001..c2d591b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -414,6 +414,8 @@ public static PersonIdent parsePersonIdent(final byte[] raw, final int nameB) {
final String email = decode(cs, raw, emailB, emailE - 1);
final MutableInteger ptrout = new MutableInteger();
+
+ // In 2038 "when" will overflow. Switch to a long before then.
final int when = parseBase10(raw, emailE + 1, ptrout);
final int tz = parseTimeZoneOffset(raw, ptrout.value);
--
1.6.1.rc3.302.gb14d9
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] gitk: force focus to main window
From: Paul Mackerras @ 2008-12-17 21:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <4948E771.4050705@viscovery.net>
Johannes Sixt writes:
> On msysGit, the focus is first on the (Tk) console. This console is then
> hidden, but keeps the focus. Work around that by forcing the focus onto
> the gitk window.
Hmmm, I don't like doing focus -force unconditionally on all
platforms. I hate it when applications decide they know best and
override what the window manager decides.
At least put a if {[tk windowingsystem] eq "win32"} in there.
(msysGit is a windows thing, isn't it?)
Paul.
^ permalink raw reply
* [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int
From: Robin Rosenberg @ 2008-12-17 22:32 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <200812172328.07371.robin.rosenberg.lists@dewire.com>
If not dates past 2038 will be parsed the wrong way when
parsed into a RevCommit or RevTag object.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/util/RawParseUtils.java | 58 +++++++++++++++++++-
1 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index 55a3001..74fe506 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -135,7 +135,7 @@ public static int formatBase10(final byte[] b, int o, int value) {
}
/**
- * Parse a base 10 numeric from a sequence of ASCII digits.
+ * Parse a base 10 numeric from a sequence of ASCII digits into an int.
* <p>
* Digit sequences can begin with an optional run of spaces before the
* sequence, and may start with a '+' or a '-' to indicate sign position.
@@ -189,6 +189,60 @@ public static final int parseBase10(final byte[] b, int ptr,
}
/**
+ * Parse a base 10 numeric from a sequence of ASCII digits into a long.
+ * <p>
+ * Digit sequences can begin with an optional run of spaces before the
+ * sequence, and may start with a '+' or a '-' to indicate sign position.
+ * Any other characters will cause the method to stop and return the current
+ * result to the caller.
+ *
+ * @param b
+ * buffer to scan.
+ * @param ptr
+ * position within buffer to start parsing digits at.
+ * @param ptrResult
+ * optional location to return the new ptr value through. If null
+ * the ptr value will be discarded.
+ * @return the value at this location; 0 if the location is not a valid
+ * numeric.
+ */
+ public static final long parseLongBase10(final byte[] b, int ptr,
+ final MutableInteger ptrResult) {
+ long r = 0;
+ int sign = 0;
+ try {
+ final int sz = b.length;
+ while (ptr < sz && b[ptr] == ' ')
+ ptr++;
+ if (ptr >= sz)
+ return 0;
+
+ switch (b[ptr]) {
+ case '-':
+ sign = -1;
+ ptr++;
+ break;
+ case '+':
+ ptr++;
+ break;
+ }
+
+ while (ptr < sz) {
+ final byte v = digits[b[ptr]];
+ if (v < 0)
+ break;
+ r = (r * 10) + v;
+ ptr++;
+ }
+ } catch (ArrayIndexOutOfBoundsException e) {
+ // Not a valid digit.
+ }
+ if (ptrResult != null)
+ ptrResult.value = ptr;
+ return sign < 0 ? -r : r;
+ }
+
+ /**
* Parse a Git style timezone string.
* <p>
* The sequence "-0315" will be parsed as the numeric value -195, as the
@@ -414,7 +468,7 @@ public static PersonIdent parsePersonIdent(final byte[] raw, final int nameB) {
final String email = decode(cs, raw, emailB, emailE - 1);
final MutableInteger ptrout = new MutableInteger();
- final int when = parseBase10(raw, emailE + 1, ptrout);
+ final long when = parseLongBase10(raw, emailE + 1, ptrout);
final int tz = parseTimeZoneOffset(raw, ptrout.value);
return new PersonIdent(name, email, when * 1000L, tz);
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* Re: [EGIT PATCH 1/2] Revert "Fix commit id in egit test T0001_ConnectProviderOperationTest"
From: Shawn O. Pearce @ 2008-12-17 22:32 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200812172328.07371.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> onsdag 17 december 2008 17:09:33 skrev Shawn O. Pearce:
> > The only thing I can think of is the timestamp we are creating by
> > the deprecated Date constructor call back on line 82. Perhaps
> > on different JVMs it is using different values for the hh:mm:ss
> > parts of the timestamp value?
>
> Indeed it is. Date is dependent on local time zone.
Thanks, much better.
--
Shawn.
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Łukasz Lew @ 2008-12-17 22:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Alexander Potashev, Nick Andrew, git
In-Reply-To: <alpine.LNX.1.00.0812171500070.19665@iabervon.org>
2008/12/17 Daniel Barkalow <barkalow@iabervon.org>:
> On Wed, 17 Dec 2008, Łukasz Lew wrote:
>
>> Well, I am still a beginner in git. I just switched from mercurial.
>> Some inline follows:
>>
>> 2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:
>> > On Sun, 14 Dec 2008, Łukasz Lew wrote:
>> >
>> >> Hi Alexander,
>> >>
>> >> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
>> >> > Hello, Łukasz!
>> >> >
>> >> > On 16:38 Sun 14 Dec , Łukasz Lew wrote:
>> >> >> Thanks Nick, thats really helpful (and surprisingly simple).
>> >> >> I have a couple more questions:
>> >> >>
>> >> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
>> >> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
>> >> >> >> I don't know how to make such a scenario work:
>> >> >> >> - two repositories: pub, priv
>> >> >> >> - priv is clone/branch of pub
>> >> >> >> - there is some constant developement both in pub and priv
>> >> >> >> - there are regular syncs with pub in priv
>> >> >> >>
>> >> >> >> Problem:
>> >> >> >> Occasionally I want to push some changes from priv to pub.
>> >> >> >> Then after syncing with pub I want to get as few conflicts as possible.
>> >> >> >>
>> >> >> >> Is it possible to do with git?
>> >> >> >
>> >> >> > Git can do almost anything. One should instead ask "How to do this
>> >> >> > with git?" :-)
>> >> >>
>> >> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.
>> >> >>
>> >> >> >
>> >> >> > If I understand your problem, you could solve it with git cherry-pick
>> >> >> > and rebase. On priv, make a for-public branch from a pub branch. Then
>> >> >> > cherry-pick the commits you want from your private branch into the
>> >> >> > for-public branch.
>> >> >>
>> >> >> That almost works. Can I somehow split existing commits just like in git-add -p?
>> >> > It's, however, better to make more commits to not experience the need of
>> >> > commit splitting.
>> >>
>> >> Indeed good advice and best practice, but another best practice is to
>> >> not commit not compiling state.
>> >
>> > In your private branches, it's actually good practice to commit all sorts
>> > of junk. That way, when you mess up badly while trying to get it to
>> > compile, you won't have lost your work. Of course, that means your commits
>> > are going to need more cleanup before going public.
>>
>> I started to follow your advise.
>> Then I rebase -i.
>> I found out I need more precise commit messages. :)
>
> One useful strategy is to have a second shell and do "git show <hash>" to
> figure out what you did in that misc commit.
Indeed!
>
>> >> My common scenario is that I code a big change in priv repository, and
>> >> after that I find that some of its parts can and should be moved to
>> >> pub.
>> >
>> > I usually end up with my private branch containing the public branch, plus
>> > a bunch of commits that introduce: bugs, later fixed; mixed improvements;
>> > and debugging cruft. I want to generate nice commits that are individual
>> > improvements. I generally do:
>> > $ git checkout -b submit origin/master (the first time, to set it up)
>> >
>> > $ git checkout submit
>> > $ git diff submit mixed-work
>> > look at it for good changes, find some in file1 and file2
>> > $ git diff submit mixed-work -- file1 file2 | git apply
>>
>> But with this command we do not preserve objects identity.
>> I.e: when you merge with mixed-work you have duplicate changes.
>> Is it ok?
>
> Git is very good about recognizing duplicate changes in 3-way situations.
> That is, merging two branches, each of which makes the same change (on a
> hunk level) to a common ancestor. It'll identify this as "the branches
> agree on a change" rather than "the branches conflict". Also, "rebase"
> will try the 3-way merge mechanism, so it will be able to sort this out.
I found that already. And I have to say that I am delighted.
This is absolutely splendid.
>
> The interesting case is when both branches have the same logical change,
> but one of them is done better than the other. When you merge these,
> you'll have to select the better one by hand in a conflict resolution.
>
>> > Sometimes, clean up bits that aren't ideal
>> > $ git add -i
>> > Add the good parts
>> > $ git checkout . (revert the working tree to the index)
>> > $ make test (did I extract the change correctly?)
>> > $ git commit
>> > Write a good message, sign off, etc
>> > $ git checkout mixed-work
>> > $ git rebase -i submit
>>
>> ... Ah I see, we throw away old commits anyway with rebasing.
>
> Yup. The old commits are there to save us when we make good changes and
> undo them before getting to a finished state. Once we reach a finished
> state, we intend to throw them away.
>
>> > Often, resolve easy conflicts where my mixed-work branch introduced bugs
>> > that I fixed later and have now adopted the fixed code
>> >
>> > Then I repeat until I don't have any more good changes in mixed-work
>> > (either I have nothing, only debugging cruft, or only stuff I haven't
>> > gotten to work yet). If there's nothing but cruft, I've fully merged the
>> > topic, and I delete the branch.
>> >
>> > Eventually, I'm satisfied with what I've cleaned up, and I do:
>> > $ git push origin submit:master
>> >
>> > Also, I generally have a bunch of "mixed-work" branches, each containing
>> > different stuff that isn't ready. I'll periodicly go through all of them
>> > and rebase onto "submit" or "origin/master" (or, sometimes, give up on
>> > them and delete them).
>> >
>> > (One thing that would be nice to have is a "git apply --interactive" which
>> > applies the user's choice of hunks, like "git add -i" adds them)
>>
>> I totally agree.
>>
>> I would appriciate rebase --copy option, which doesn't move, but copy
>> the changelists like cherry-pick.
>
> There's work in progress on a generalization of "rebase -i" that could be
> seeded with the "cherry-pick" operations instead of the "rebase"
> operations. I think that's what you'd like.
I always wanted to have system that would allow me manipulation of
patches as features.
I.e: I have one patch for feature X, one for Y, one for debugging X,
one for debugging Y, etc.
Then I would just pick some of them, work with them to create new ones.
The basic operations would be use/unuse patch, combine sequence of
patches into one (with commit messages of subpatches saved somewhere),
uncombine patch into sequence of patches.
Easy way of spliting atomic patch (diff) into several more so I can
add more commit messages.
Now this would resemble directory structure, I could copy/move/remove
patches from/to various bigger packs of patches. Merging would detect
duplicates of course.
Git took me for the first time close to this ideal.
> On the other hand, remember
> that you can just make a new branch based on your endpoint and rebase it
> on your upstream; there's no reason that you can't "unzip" the history
> past the point where the branch you're modifying was created.
I never thought about that. It works indeed.
>
>> Then we could use rebase -i (with edit) instead of apply.
>>
>> PS
>> Why after edit in rebase -i the change is already commited? I always
>> have to reset;add -i
>
> There's (currently) no equivalent of the index (storing the contents of
> the commit in progress) for the message (and author info, etc). On the
> other hand, you can use "git commit --amend" to alter the commit on top
> (including the files), and you can do "git diff HEAD HEAD^ | git apply" to
> get reverts into your worktree that you can add (or not add).
Good idea, thanks.
BTW is it diff | apply the same as revert --no-commit?
>
> The common case for edit, I think, is that things are mostly correct, but
> there's a wrong change; with the change already committed, it's easy to
> change it to what it should be and "git commit -a --amend".
>
> -Daniel
> *This .sig left intentionally blank*
^ permalink raw reply
* Re: [EGIT PATCH 1/2] Revert "Fix commit id in egit test T0001_ConnectProviderOperationTest"
From: Robin Rosenberg @ 2008-12-17 22:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081217160933.GD32487@spearce.org>
onsdag 17 december 2008 17:09:33 skrev Shawn O. Pearce:
> The only thing I can think of is the timestamp we are creating by
> the deprecated Date constructor call back on line 82. Perhaps
> on different JVMs it is using different values for the hh:mm:ss
> parts of the timestamp value?
Indeed it is. Date is dependent on local time zone.
>From e4d10dea5d62210868d71384e559a0d3ef1ca55d Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Wed, 17 Dec 2008 22:46:48 +0100
Subject: [EGIT PATCH 1/2 v2] Fix testcase that was sensitive to the local time zone.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../op/T0001_ConnectProviderOperationTest.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
index 0ce2d7f..092c048 100644
--- a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
+++ b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
@@ -80,7 +80,7 @@ public void testNewUnsharedFile() throws CoreException, IOException,
Commit commit = new Commit(thisGit);
commit.setTree(rootTree);
commit.setAuthor(new PersonIdent("J. Git", "j.git@egit.org", new Date(
- 1999, 1, 1), TimeZone.getTimeZone("GMT+1")));
+ 60876075600000L), TimeZone.getTimeZone("GMT+1")));
commit.setCommitter(commit.getAuthor());
commit.setMessage("testNewUnsharedFile\n\nJunit tests\n");
ObjectId id = writer.writeCommit(commit);
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* Re: git-diff should not fire up $PAGER, period!
From: Linus Torvalds @ 2008-12-17 22:04 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763lixyps.fsf_-_@jidanni.org>
On Thu, 18 Dec 2008, jidanni@jidanni.org wrote:
>
> Gentlemen, I have found the solution to your problem.
Umm. YOUR problem.
Do that whole
[core]
pager =
and you can get the behaviour you want.
Or just get rid of emacs. Your problem has nothing to do with git, and
everything to do with emacs. And then you have the _gall_ to talk about
"unix design" and not gumming programs together, when you yourself use the
most gummed-up piece of absolute sh*t there is!
Linus
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Junio C Hamano @ 2008-12-17 22:02 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763lixyps.fsf_-_@jidanni.org>
jidanni@jidanni.org writes:
> I mean here I am in emacs, and
>
> -*- mode: compilation; default-directory: "...coreutils/" -*-
> Compilation started at Thu Dec 18 03:15:14
> git-diff
> WARNING: terminal is not fully functional^M
> ^M- (press RETURN)
Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
in compilation mode (and possibly shell mode), so this is not a problem in
practice.
I have something like this in my .emacs:
(setenv "PAGER" "cat")
I suspect (I am just a user not a hacker) this will have bad interaction
with emacs terminal emulation mode, but I do not use the mode, so it is
enough for me.
^ permalink raw reply
* Re: git-format-patch patch
From: Miklos Vajna @ 2008-12-17 21:55 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <877i5yy149.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
On Thu, Dec 18, 2008 at 04:53:42AM +0800, jidanni@jidanni.org wrote:
> I'm still reading the manpage about submitting proper patches, so for now:
It is not a manual page, it lives under Documentation/SubmittingPatches.
Problems with the current patch:
- It is not a unidiff.
- No signoff
- No commit message
Hope this helps. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-diff should not fire up $PAGER, period!
From: jidanni @ 2008-12-17 21:45 UTC (permalink / raw)
To: git
In-Reply-To: <20081216005658.GB3679@coredump.intra.peff.net>
Gentlemen, I have found the solution to your problem.
Unbundle git-diff and $PAGER.
Ask yourself, does diff(1) call $PAGER?
No. That's because the Unix designers were smart enough not to glue
everything together.
Now's your chance to repent, as you haven't even yet mentioned $PAGER
on the git-diff man page. Yes, do mention it: "EXAMPLES: git-diff|less"
I.e., the user can page the output if he feels inclined, just like any
other output. I mean one already has a wallet. The bank need not give
the user one every time they make a withdraw.
I mean here I am in emacs, and
-*- mode: compilation; default-directory: "...coreutils/" -*-
Compilation started at Thu Dec 18 03:15:14
git-diff
WARNING: terminal is not fully functional^M
^M- (press RETURN)
"It's all emacs' fault for emulating a tty too well"... no, it's all
your fault for gumming things together. No I don't want my cookies
with obligatory milk. I'll using git-diff|cat for now instead of
complaining that emacs is all wrong. Even using git-diff|cat|less is
better than messing with the LESS=F bug. Repent, whippersnappers!
OK, doing test x$EMACS = xt && PAGER=cat in .bashrc. That will help
for emacs' shell buffers, but not compilation mode buffers... "then
just make a hook"... 13 hooks to combat one poor design choice.
And one notices git-show is gummed up too.
Hmm, looking in changelogs, we see
* Error messages used to be sent to stderr, only to get hidden,
when $PAGER was in use. They now are sent to stdout along
with the command output to be shown in the $PAGER.
Well, if you had left paging to the user, no one would have blamed you
for making error messages disappear, and you could have left stderr as
the elders intended.
Wait,
$ git-config --global core.pager ""
Cool. Bye.
^ permalink raw reply
* Re: [PATCH 1/5] Add generic 'strbuf_readlink()' helper function
From: Linus Torvalds @ 2008-12-17 21:44 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <76718490812171326q4d8896c1yb535873c71eec23f@mail.gmail.com>
On Wed, 17 Dec 2008, Jay Soffian wrote:
> > + /* .. the buffer was too small - try again */
> > + hint *= 2;
> > + continue;
> > + }
>
> Why the continue statement at the end of the loop?
Oh, it's unnecessary left-over from me originally writing that part inside
an if-statement, and then moving things around.
So it could/should be deleted. Good eyes.
Linus
^ permalink raw reply
* Re: [PATCH 8/5] combine-diff.c: use strbuf_readlink()
From: Junio C Hamano @ 2008-12-17 21:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171300070.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 17 Dec 2008, Junio C Hamano wrote:
>> - result[len] = 0;
>> + result_size = buf.len;
>> + result = strbuf_detach(&buf, NULL);
>
> If result_size was made size_t, this would be
>
> result = strbuf_detach(&buf, &result_size);
>
> But whether it makes any difference, I dunno.
Yeah, use of "unsigned long" where "size_t" could be more appropriate
stems from the very initial commit e83c516 (Initial revision of "git", the
information manager from hell, 2005-04-07) and it is everywhere, and
updating them one by one like you suggest would take forever ;-)
Perhaps libgit2 would settle with a better typing system. The original
draft by Shawn looked a bit too overengineered in its use of typedefs, but
if I recall correctly later revisions were made saner. I haven't checked
its current status.
^ permalink raw reply
* [PATCH] githooks documentation: add a note about the +x mode
From: Miklos Vajna @ 2008-12-17 21:29 UTC (permalink / raw)
To: gitster; +Cc: Johannes Sixt, Markus Heidelberg, git
In-Reply-To: <200812172055.45905.markus.heidelberg@web.de>
In a freshly initialized repo it is only necessary to rename the .sample
hooks, but when using older repos (initialized with older git init)
enabled the +x mode is still necessary - docuement this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Dec 17, 2008 at 08:55:45PM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> When you want to learn how to use hooks, you will probably rather read
> githooks(5), where the need for the executable bit is not even
> explicitly mentioned. Maybe it should be added there?
I think so.
Documentation/githooks.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 5faaaa5..cfdae1e 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -20,6 +20,10 @@ directory to trigger action at certain points. When
all disabled. To enable a hook, rename it by removing its `.sample`
suffix.
+NOTE: It is also a requirement for a given hook to be executable.
+However - in a freshly initialized repository - the `.sample` files are
+executable by default.
+
This document describes the currently defined hooks.
applypatch-msg
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: [PATCH 1/5] Add generic 'strbuf_readlink()' helper function
From: Jay Soffian @ 2008-12-17 21:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171042120.14014@localhost.localdomain>
On Wed, Dec 17, 2008 at 1:42 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> + while (hint < STRBUF_MAXLINK) {
> + int len;
> +
> + strbuf_grow(sb, hint);
> + len = readlink(path, sb->buf, hint);
> + if (len < 0) {
> + if (errno != ERANGE)
> + break;
> + } else if (len < hint) {
> + strbuf_setlen(sb, len);
> + return 0;
> + }
> +
> + /* .. the buffer was too small - try again */
> + hint *= 2;
> + continue;
> + }
Why the continue statement at the end of the loop?
j.
^ permalink raw reply
* git-format-patch patch
From: jidanni @ 2008-12-17 20:53 UTC (permalink / raw)
To: git
I'm still reading the manpage about submitting proper patches, so for now:
*** /tmp/git-format-patch.txt 2008-12-18 04:41:34.050800884 +0800
--- /tmp/git-format-patchNEW.txt 2008-12-18 04:46:25.738801367 +0800
***************
*** 127,133 ****
--in-reply-to=Message-Id::
Make the first mail (or all the mails with --no-thread) appear as a
reply to the given Message-Id, which avoids breaking threads to
! provide a new patch series.
--ignore-if-in-upstream::
Do not include a patch that matches a commit in
--- 127,134 ----
--in-reply-to=Message-Id::
Make the first mail (or all the mails with --no-thread) appear as a
reply to the given Message-Id, which avoids breaking threads to
! provide a new patch series. Generates coresponding References and
! In-Reply-To headers. Angle brackets around <Message-Id> are optional.
--ignore-if-in-upstream::
Do not include a patch that matches a commit in
^ permalink raw reply
* Re: [PATCH 8/5] combine-diff.c: use strbuf_readlink()
From: Linus Torvalds @ 2008-12-17 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v63lileqh.fsf@gitster.siamese.dyndns.org>
On Wed, 17 Dec 2008, Junio C Hamano wrote:
> - result[len] = 0;
> + result_size = buf.len;
> + result = strbuf_detach(&buf, NULL);
If result_size was made size_t, this would be
result = strbuf_detach(&buf, &result_size);
But whether it makes any difference, I dunno.
Anyway, Ack on the 6-8 additions.
Linus
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Henk @ 2008-12-17 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <1229543462897-1669467.post@n2.nabble.com>
tekkub wrote:
>
> Very nice, however I ran into the following error while trying to install:
> http://www.flickr.com/photos/26681170@N03/3115836831/
>
I just rereleased a 0.9 version without the visual studio plugin. Too bad it
causes problems, I will try to fix them soon. I was able to reproduce the
error on my laptop, so thats a good start.
The new installer is downloadable here:
https://sourceforge.net/project/showfiles.php?group_id=246547&package_id=300816
https://sourceforge.net/project/showfiles.php?group_id=246547&package_id=300816
--
View this message in context: http://n2.nabble.com/Announcement%3A-Git-Extensions-stable-%28windows-shell-extensions%29-tp1669264p1669761.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Add git-edit-index.perl
From: Neil Roberts @ 2008-12-17 20:47 UTC (permalink / raw)
To: git
This script can be used to edit a file in the index without affecting
your working tree. It checkouts a copy of the file to a temporary file
and runs an editor on it. If the editor completes successfully with a
non-empty file then it updates the index with the new data.
This is useful to fine tune the results from git add -p. For example
sometimes your unrelated changes are too close together and
git-add--interactive will refuse to split them up. Using this script
you can add both the changes and later edit the index file to
temporarily remove one of the changes.
Signed-off-by: Neil Roberts <bpeeluk@yahoo.co.uk>
---
.gitignore | 1 +
Makefile | 1 +
git-edit-index.perl | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 100 insertions(+), 0 deletions(-)
create mode 100755 git-edit-index.perl
diff --git a/.gitignore b/.gitignore
index d9adce5..251d90b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,7 @@ git-diff-files
git-diff-index
git-diff-tree
git-describe
+git-edit-index
git-fast-export
git-fast-import
git-fetch
diff --git a/Makefile b/Makefile
index 5158197..77ee97f 100644
--- a/Makefile
+++ b/Makefile
@@ -275,6 +275,7 @@ SCRIPT_PERL += git-archimport.perl
SCRIPT_PERL += git-cvsexportcommit.perl
SCRIPT_PERL += git-cvsimport.perl
SCRIPT_PERL += git-cvsserver.perl
+SCRIPT_PERL += git-edit-index.perl
SCRIPT_PERL += git-relink.perl
SCRIPT_PERL += git-send-email.perl
SCRIPT_PERL += git-svn.perl
diff --git a/git-edit-index.perl b/git-edit-index.perl
new file mode 100755
index 0000000..a5d9886
--- /dev/null
+++ b/git-edit-index.perl
@@ -0,0 +1,98 @@
+#!/usr/bin/perl -w
+#
+# Copyright 2008 Neil Roberts <bpeeluk@yahoo.co.uk>
+#
+# GPL v2 (See COPYING)
+#
+# Opens an editor on a copy of a file in the index and updates it when
+# the editor is finished. This can be used to fine tune to results of
+# git add -p
+
+use strict;
+use warnings;
+use Git;
+
+sub usage {
+ print <<EOT;
+git edit-index <file>...
+EOT
+ exit(1);
+}
+
+sub delete_temp_files {
+ # Delete the temporary files created by checkout-index
+ # --temp. The output from checkout-index should be passed as
+ # arguments
+ foreach my $fnfull (@_) {
+ my ($tmp_fn, $fn) = split(/\t/, $fnfull);
+ unlink($tmp_fn);
+ }
+}
+
+sub check_file_size {
+ my ($fn) = @_;
+ my ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size,
+ $atime, $mtime, $ctime, $blksize, $blocks) = stat($fn);
+
+ $size;
+}
+
+usage unless @ARGV;
+
+my $repo = Git->repository();
+
+my %file_modes;
+
+my $editor = $ENV{GIT_EDITOR}
+ || $repo->config("core.editor")
+ || $ENV{VISUAL}
+ || $ENV{EDITOR}
+ || "vi";
+
+# Create a temporary copy of each file in the index
+my @file_list = $repo->command(qw(checkout-index --temp --), @ARGV);
+
+# Get the current mode of each file
+foreach my $fnfull (@file_list) {
+ my ($tmp_fn, $fn) = split(/\t/, $fnfull);
+ my ($file_details) = $repo->command_oneline(qw(ls-files --stage --),
+ $fn);
+ unless (defined($file_details) && $file_details =~ /\A([0-7]{6}) /)
+ {
+ delete_temp_files(@file_list);
+ die("$fn is not in the index");
+ }
+
+ $file_modes{$fn} = $1;
+}
+
+# Edit each file
+foreach my $fnfull (@file_list) {
+ my ($tmp_fn, $fn) = split(/\t/, $fnfull);
+
+ unless (system($editor, $tmp_fn) == 0
+ && check_file_size($tmp_fn)) {
+ # If the editor failed, the file has disappeared or it
+ # has zero size then give up
+ delete_temp_files(@file_list);
+ die("Editor failed or file has zero size");
+ }
+}
+
+# Add each file back to the index
+foreach my $fnfull (@file_list) {
+ my ($tmp_fn, $fn) = split(/\t/, $fnfull);
+
+ my $hash = $repo->command_oneline(qw(hash-object -w --), $tmp_fn);
+
+ unless (defined($hash) && $hash =~ /\A[0-9a-f]{40}\z/) {
+ delete_temp_files(@file_list);
+ die("Failed to add new file");
+ }
+
+ $repo->command(qw(update-index --cacheinfo),
+ $file_modes{$fn}, $hash, $fn);
+}
+
+# Clean up the temporary files
+delete_temp_files(@file_list);
--
1.5.6.3
^ permalink raw reply related
* [PATCH 8/5] combine-diff.c: use strbuf_readlink()
From: Junio C Hamano @ 2008-12-17 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171044110.14014@localhost.localdomain>
When showing combined diff using work tree contents, use strbuf_readlink()
to read symbolic links.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
combine-diff.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git i/combine-diff.c w/combine-diff.c
index ec8df39..bccc018 100644
--- i/combine-diff.c
+++ w/combine-diff.c
@@ -703,15 +703,15 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
goto deleted_file;
if (S_ISLNK(st.st_mode)) {
- size_t len = xsize_t(st.st_size);
- result_size = len;
- result = xmalloc(len + 1);
- if (result_size != readlink(elem->path, result, len)) {
+ struct strbuf buf = STRBUF_INIT;
+
+ if (strbuf_readlink(&buf, elem->path, st.st_size) < 0) {
error("readlink(%s): %s", elem->path,
strerror(errno));
return;
}
- result[len] = 0;
+ result_size = buf.len;
+ result = strbuf_detach(&buf, NULL);
elem->mode = canon_mode(st.st_mode);
}
else if (0 <= (fd = open(elem->path, O_RDONLY)) &&
^ permalink raw reply related
* [PATCH 6/5] make_absolute_path(): check bounds when seeing an overlong symlink
From: Junio C Hamano @ 2008-12-17 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171044110.14014@localhost.localdomain>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
abspath.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git i/abspath.c w/abspath.c
index 8194ce1..649f34f 100644
--- i/abspath.c
+++ w/abspath.c
@@ -64,6 +64,8 @@ const char *make_absolute_path(const char *path)
len = readlink(buf, next_buf, PATH_MAX);
if (len < 0)
die ("Invalid symlink: %s", buf);
+ if (PATH_MAX <= len)
+ die("symbolic link too long: %s", buf);
next_buf[len] = '\0';
buf = next_buf;
buf_index = 1 - buf_index;
^ permalink raw reply related
* [PATCH 7/5] builtin-blame.c: use strbuf_readlink()
From: Junio C Hamano @ 2008-12-17 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171044110.14014@localhost.localdomain>
When faking a commit out of the work tree contents, use strbuf_readlink()
to read the contents of symbolic links.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-blame.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git i/builtin-blame.c w/builtin-blame.c
index a0d6014..aae14ef 100644
--- i/builtin-blame.c
+++ w/builtin-blame.c
@@ -1996,7 +1996,6 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
if (!contents_from || strcmp("-", contents_from)) {
struct stat st;
const char *read_from;
- unsigned long fin_size;
if (contents_from) {
if (stat(contents_from, &st) < 0)
@@ -2008,7 +2007,6 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
die("Cannot lstat %s", path);
read_from = path;
}
- fin_size = xsize_t(st.st_size);
mode = canon_mode(st.st_mode);
switch (st.st_mode & S_IFMT) {
case S_IFREG:
@@ -2016,9 +2014,8 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
die("cannot open or read %s", read_from);
break;
case S_IFLNK:
- if (readlink(read_from, buf.buf, buf.alloc) != fin_size)
+ if (strbuf_readlink(&buf, read_from, st.st_size) < 0)
die("cannot readlink %s", read_from);
- buf.len = fin_size;
break;
default:
die("unsupported file type %s", read_from);
^ permalink raw reply related
* Re: [PATCH 4/5] Make 'diff_populate_filespec()' use the new 'strbuf_readlink()'
From: Junio C Hamano @ 2008-12-17 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171043440.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> diff --git a/diff.c b/diff.c
> index afefe08..4b2029c 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1773,19 +1773,17 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
> s->size = xsize_t(st.st_size);
> if (!s->size)
> goto empty;
> - if (size_only)
> - return 0;
> if (S_ISLNK(st.st_mode)) {
> ...
> }
> + if (size_only)
> + return 0;
It is unfortunate that we need to always readlink even when we only would
want to cull differences early (e.g. --raw without any fancy filters such
as rename detection), but symbolic links should be minorities in any sane
repo, and it should not be worth trying to optimize this for sane
filesystems by making it conditional.
^ permalink raw reply
* Re: [PATCH 3/5] Make 'index_path()' use 'strbuf_readlink()'
From: Junio C Hamano @ 2008-12-17 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171043180.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> @@ -2537,20 +2536,17 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
> path);
> break;
> case S_IFLNK:
> - len = xsize_t(st->st_size);
> - target = xmalloc(len + 1);
> - if (readlink(path, target, len + 1) != st->st_size) {
> + if (strbuf_readlink(&sb, path, st->st_size)) {
> char *errstr = strerror(errno);
> - free(target);
> return error("readlink(\"%s\"): %s", path,
> errstr);
Thanks; as strbuf_readlink() does not do any iffy library calls that would
stomp on errno, the error reporting should still be valid here.
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Junio C Hamano @ 2008-12-17 20:30 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0812171157m3d180534gb5630fbcf39b2bbd@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> My question is this: is it possible to revert the changes that I
> haven't staged so that the file looks as if everything inside of it
> has been staged because none of the stuff I didn't stage is there
> anymore.
The last part of the sentence after "because" does not parse for me at
all, but I think you are after one of the following:
(1) if you want to get rid of garbage changes in your work tree, you
would want "git checkout $that_path";
(2) if you want to temporarily stash away further changes in your work
tree, because you would want to first test what is staged, commit it,
and then later continue to refine the changes stashed away thusly,
you would want "git stash --keep-index".
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Daniel Barkalow @ 2008-12-17 20:27 UTC (permalink / raw)
To: Łukasz Lew; +Cc: Alexander Potashev, Nick Andrew, git
In-Reply-To: <c55009e70812171157s7932c0b3u7a8ee6557c140d56@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6752 bytes --]
On Wed, 17 Dec 2008, Łukasz Lew wrote:
> Well, I am still a beginner in git. I just switched from mercurial.
> Some inline follows:
>
> 2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:
> > On Sun, 14 Dec 2008, Łukasz Lew wrote:
> >
> >> Hi Alexander,
> >>
> >> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
> >> > Hello, Łukasz!
> >> >
> >> > On 16:38 Sun 14 Dec , Łukasz Lew wrote:
> >> >> Thanks Nick, thats really helpful (and surprisingly simple).
> >> >> I have a couple more questions:
> >> >>
> >> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
> >> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
> >> >> >> I don't know how to make such a scenario work:
> >> >> >> - two repositories: pub, priv
> >> >> >> - priv is clone/branch of pub
> >> >> >> - there is some constant developement both in pub and priv
> >> >> >> - there are regular syncs with pub in priv
> >> >> >>
> >> >> >> Problem:
> >> >> >> Occasionally I want to push some changes from priv to pub.
> >> >> >> Then after syncing with pub I want to get as few conflicts as possible.
> >> >> >>
> >> >> >> Is it possible to do with git?
> >> >> >
> >> >> > Git can do almost anything. One should instead ask "How to do this
> >> >> > with git?" :-)
> >> >>
> >> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.
> >> >>
> >> >> >
> >> >> > If I understand your problem, you could solve it with git cherry-pick
> >> >> > and rebase. On priv, make a for-public branch from a pub branch. Then
> >> >> > cherry-pick the commits you want from your private branch into the
> >> >> > for-public branch.
> >> >>
> >> >> That almost works. Can I somehow split existing commits just like in git-add -p?
> >> > It's, however, better to make more commits to not experience the need of
> >> > commit splitting.
> >>
> >> Indeed good advice and best practice, but another best practice is to
> >> not commit not compiling state.
> >
> > In your private branches, it's actually good practice to commit all sorts
> > of junk. That way, when you mess up badly while trying to get it to
> > compile, you won't have lost your work. Of course, that means your commits
> > are going to need more cleanup before going public.
>
> I started to follow your advise.
> Then I rebase -i.
> I found out I need more precise commit messages. :)
One useful strategy is to have a second shell and do "git show <hash>" to
figure out what you did in that misc commit.
> >> My common scenario is that I code a big change in priv repository, and
> >> after that I find that some of its parts can and should be moved to
> >> pub.
> >
> > I usually end up with my private branch containing the public branch, plus
> > a bunch of commits that introduce: bugs, later fixed; mixed improvements;
> > and debugging cruft. I want to generate nice commits that are individual
> > improvements. I generally do:
> > $ git checkout -b submit origin/master (the first time, to set it up)
> >
> > $ git checkout submit
> > $ git diff submit mixed-work
> > look at it for good changes, find some in file1 and file2
> > $ git diff submit mixed-work -- file1 file2 | git apply
>
> But with this command we do not preserve objects identity.
> I.e: when you merge with mixed-work you have duplicate changes.
> Is it ok?
Git is very good about recognizing duplicate changes in 3-way situations.
That is, merging two branches, each of which makes the same change (on a
hunk level) to a common ancestor. It'll identify this as "the branches
agree on a change" rather than "the branches conflict". Also, "rebase"
will try the 3-way merge mechanism, so it will be able to sort this out.
The interesting case is when both branches have the same logical change,
but one of them is done better than the other. When you merge these,
you'll have to select the better one by hand in a conflict resolution.
> > Sometimes, clean up bits that aren't ideal
> > $ git add -i
> > Add the good parts
> > $ git checkout . (revert the working tree to the index)
> > $ make test (did I extract the change correctly?)
> > $ git commit
> > Write a good message, sign off, etc
> > $ git checkout mixed-work
> > $ git rebase -i submit
>
> ... Ah I see, we throw away old commits anyway with rebasing.
Yup. The old commits are there to save us when we make good changes and
undo them before getting to a finished state. Once we reach a finished
state, we intend to throw them away.
> > Often, resolve easy conflicts where my mixed-work branch introduced bugs
> > that I fixed later and have now adopted the fixed code
> >
> > Then I repeat until I don't have any more good changes in mixed-work
> > (either I have nothing, only debugging cruft, or only stuff I haven't
> > gotten to work yet). If there's nothing but cruft, I've fully merged the
> > topic, and I delete the branch.
> >
> > Eventually, I'm satisfied with what I've cleaned up, and I do:
> > $ git push origin submit:master
> >
> > Also, I generally have a bunch of "mixed-work" branches, each containing
> > different stuff that isn't ready. I'll periodicly go through all of them
> > and rebase onto "submit" or "origin/master" (or, sometimes, give up on
> > them and delete them).
> >
> > (One thing that would be nice to have is a "git apply --interactive" which
> > applies the user's choice of hunks, like "git add -i" adds them)
>
> I totally agree.
>
> I would appriciate rebase --copy option, which doesn't move, but copy
> the changelists like cherry-pick.
There's work in progress on a generalization of "rebase -i" that could be
seeded with the "cherry-pick" operations instead of the "rebase"
operations. I think that's what you'd like. On the other hand, remember
that you can just make a new branch based on your endpoint and rebase it
on your upstream; there's no reason that you can't "unzip" the history
past the point where the branch you're modifying was created.
> Then we could use rebase -i (with edit) instead of apply.
>
> PS
> Why after edit in rebase -i the change is already commited? I always
> have to reset;add -i
There's (currently) no equivalent of the index (storing the contents of
the commit in progress) for the message (and author info, etc). On the
other hand, you can use "git commit --amend" to alter the commit on top
(including the files), and you can do "git diff HEAD HEAD^ | git apply" to
get reverts into your worktree that you can add (or not add).
The common case for edit, I think, is that things are mostly correct, but
there's a wrong change; with the change already committed, it's easy to
change it to what it should be and "git commit -a --amend".
-Daniel
*This .sig left intentionally blank*
^ 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