On Sat, Apr 20, 2013 at 10:44 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Johan Herland wrote:
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo and there is exactly one remote
with a remote-tracking branch called foo
by such a
requirement?
- Is it preferable to stop after patch #4, and accept the superset of
refs/remotes/* and refspec-matching refs as valid remote-tracking
branches?
Have fun! :)
...Johan
Johan Herland (5):
t2024: Add tests verifying current DWIM behavior of 'git checkout branch'
t2024
starting point and configured upstream.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 66
1 file changed, 66 insertions(+)
create mode 100755 t/t2024-checkout-dwim.sh
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024
-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 5650d21..36bf52f 100755
--- a/t/t2024-checkout-dwim.sh
+++ b
exist in our local repo, then
we have found the upstream for the new local branch foo.
This fixes most of the failing tests introduced in the previous patch.
Signed-off-by: Johan Herland jo...@herland.net
---
Documentation/git-checkout.txt | 6 +++---
builtin/checkout.c | 42
/*.
This new check is added as a fallback after checking for match against
refs/heads/* and refs/remotes/*, so the code will not be run in the common
case.
This patch also fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland jo...@herland.net
---
branch.c
The previous patch adds validation of upstream remote-tracking branches by
parsing the configured refspecs, and making sure that the candidate upstream
(if not already matching refs/heads/* or refs/remotes/*) is indeed a
remote-tracking branch according to some remote's refspec. For a
checkout master
Too many commands. I want to do this with just one command. And I want
to stay be on branch master in case of rebase conflicts.
git cherry-pick master..origin/master
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line
-by: Johan Herland jo...@herland.net
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
graph_set_column_colors
specifically so that CGit should use it - there's no value to having
that as a method just for its use in graph.c and he was the author of
CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
Correct,
Acked-by: Johan Herland jo...@herland.net
Have fun
the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
On Tue, Nov 6, 2012 at 8:56 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 11/04/2012 10:05 PM, Johan Herland wrote:
On Sun, Nov 4, 2012 at 8:07 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
This simplifies the code. Also, sort lines all at once (O(N lg N))
rather than insertion
the testcase and subsequent fix in a single commit.
Have fun! :)
...Johan
Johan Herland (2):
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Fix failure to delete a packed ref through a symref
refs.c| 2 +-
t/t1400-update-ref.sh | 18
When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD'
to delete refs/heads/master), we currently fail to remove the packed
version of that ref. This testcase demonstrates the bug.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t1400-update-ref.sh | 18
as of
the last repack.
This patch fixes the issue, by making sure we pass the correct ref name
when invoking repack_without_ref() from within delete_ref().
Signed-off-by: Johan Herland jo...@herland.net
---
refs.c| 2 +-
t/t1400-update-ref.sh | 2 +-
2 files changed, 2 insertions(+), 2
symref, and then invoking delete_ref() on it with the REF_NODEREF
flag.
Signed-off-by: Johan Herland jo...@herland.net
---
Here is a quick first attempt at implementing the 'git symbolic-ref -d'
you've been mentioning in the symref deletion thread.
Documentation/git-symbolic-ref.txt | 10
the dereferenced ref's reflog instead of the symref's reflog.
Patch #4 - #5 introduces solution A presented in my previous mail (i.e.
'git branch -d' never dereferences symrefs).
Johan Herland (5):
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
delete_ref(): Fix deletion
When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD'
to delete refs/heads/master), we currently fail to remove the packed
version of that ref. This testcase demonstrates the bug.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t1400-update-ref.sh | 18
the logic in delete_ref() to make it easier to read,
and to clarify how it operates when given a symref.
Signed-off-by: Johan Herland jo...@herland.net
---
refs.c| 33 +
t/t1400-update-ref.sh | 2 +-
2 files changed, 18 insertions(+), 17 deletions
branch -d), at which point they incorrectly delete the
proper branch name instead of the alias. This is reflected in these tests,
and will be fixed in a subsequent patch.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t3220-symbolic-ref-as-branch-alias.sh | 53
With refs/heads/alias set up as a symref to refs/heads/master,
'git branch -d alias' should remove refs/heads/alias and not
refs/heads/master.
Signed-off-by: Johan Herland jo...@herland.net
---
builtin/branch.c| 2 +-
t/t3220-symbolic-ref-as-branch-alias.sh | 2 +-
2
When deleting a symref (e.g. HEAD), we would incorrectly remove the
reflog of the dereferenced ref (e.g. .git/logs/refs/heads/master),
insted of the symref's reflog (e.g. .git/logs/HEAD).
This patch ensures that we remove the reflog that corresponds to the
removed (sym)ref.
Signed-off-by: Johan
be less helpful for us, but Git would at least be
internally consistent (in that the symref would be resolved, and the
command would become git branch -d master).
Obviously, I would advocate for option A. What say you?
Have fun! :)
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
The following works in the git.git repo:
$ cd t
$ git log -- /Documentation
[...]
but the following does not:
$ cd t
$ git log -- /Documentation/RelNotes
fatal: Could not switch to '/Documentation': No such file or directory
Is this the intended behavior?
...Johan
--
Johan Herland, jo
, and I
question about git log -- /Documentation/RelNotes was misguided.
Thanks for clearing up my confusion.
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
.
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
://thread.gmane.org/gmane.comp.version-control.git/160503
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 5, 2012 at 2:52 PM, W. Trevor King wk...@tremily.us wrote:
From: W. Trevor King wk...@tremily.us
Useful for debugging refs that don't seem to be expanding correctly.
Signed-off-by: W. Trevor King wk...@tremily.us
Acked-by: Johan Herland jo...@herland.net
--
Johan Herland, jo
On Wed, Sep 5, 2012 at 7:53 PM, W. Trevor King wk...@tremily.us wrote:
On Wed, Sep 05, 2012 at 05:58:37PM +0200, Johan Herland wrote:
On Wed, Sep 5, 2012 at 2:48 PM, W. Trevor King wk...@tremily.us wrote:
If I'm missing a good reason to keep everything under
'refs/notes/', feel free
301 - 329 of 329 matches
Mail list logo