On 13-12-18 11:04 AM, Marc Branchaud wrote:
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that is almost always backwards in time. Replacing the text with arrows
makes it clear where the buttons will take
On 14-03-14 12:37 AM, Andrew Wong wrote:
During a merge, --mixed is most likely not what the user wants. Using
--mixed during a merge would leave the merged changes and new files
mixed in with the local changes. The user would have to manually clean
up the work tree, which is non-trivial. In
On 14-03-14 04:55 PM, Junio C Hamano wrote:
So I am OK with eventually error out by default, but not OK with
we know better than the user and will not allow it at all.
Can I interpret that as you being OK with my proposed Cowardly
refusing approach?
M.
--
To unsubscribe
On 14-04-28 02:41 PM, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
Problem #1: TortoiseGit GUI windows for common tasks have a heck
lots of controls that a common Git user will never need.
Do people around TortoiseGit lurk on this list? Otherwise this may
not be
On 14-04-30 10:55 AM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations
On 14-04-30 04:01 PM, Junio C Hamano wrote:
Maybe I was unclear.
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does.
That's
On 14-04-30 04:14 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead
me to start using git pull let alone recommending it to new users.
What is wrong
On 14-05-01 05:46 AM, brian m. carlson wrote:
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
What is wrong when `git pull` merges a fast-forward?
Nothing. Everything. It depends.
It depends on what? I
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to the latest from the main repo.
git pull --ff-only
git pull
On 14-05-01 03:22 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
What's more, it seems to me that the only real advantage git pull
provides here is a less typing compared to the non-pull equivalent:
git fetch main-repo
git checkout main-repo/maintenance-branch
git fetch developer
On 14-05-01 02:30 PM, W. Trevor King wrote:
I find a local branch useful to mark the amount of the upstream branch
that I've reviewed. The reflog helps a bit, but I may go several
fetches between reviews. For newbies, I recommend avoiding detached
HEADs, where possible, so they don't have
(Apologies for not CCing all the folks who've participated in the Pull is
Evil thread -- I couldn't find a good branch of that thread for this message.)
OK, so maybe git pull is just Mostly Evil. People seem to have found many
different ways to make it work for them.
But in reality git pull
After poking this hornet's nest I pretty much have stood back and not
participated in the ensuing discussions. But having unleashed the hornets I
feel I should at least say something, if only to assure people that I'm not
ignoring their plight.
There have been various proposals to modify
On 14-08-16 12:06 PM, Christian Couder wrote:
While at it add git-interpret-trailers to command-list.txt.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-interpret-trailers.txt | 308
On 14-08-20 11:39 PM, Christian Couder wrote:
On Thu, Aug 21, 2014 at 12:05 AM, Marc Branchaud marcn...@xiplink.com wrote:
On 14-08-16 12:06 PM, Christian Couder wrote:
+
+* after them it's only possible to have some lines that contain only
+ spaces, and then a patch; the patch part
On 14-08-19 12:07 PM, Robert Dailey wrote:
On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Thanks for reporting. The remote used is the default remote that git
fetch without further arguments would use:
get_default_remote () {
, but not today.
Both Heiko and Robert took issue with this statement of mine:
On 14-08-22 12:00 PM, Marc Branchaud wrote:
A branch should fork the entire repo, including its submodules. The
implication is that if you want to push that branch somewhere, that
somewhere needs to be able to accept the forks
On 14-09-08 06:52 AM, Duy Nguyen wrote:
While we're changing the terms, I wonder if primary working
directory and secondary working directories are better than main
checkout and linked checkout.
I might have a slight preference for main/linked, because primary/secondary
can imply that there
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
git checkout --to sets up a new working directory with a .git file
pointing to $GIT_DIR/worktrees/id. It then executes git checkout
again on the new worktree with the same arguments except --to is
taken out. The second checkout execution, which
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
(alias R=$GIT_COMMON_DIR/worktrees/id)
- linked checkouts are supposed to keep its location in $R/gitdir up
to date. The use case is auto fixup after a manual checkout move.
- linked checkouts are supposed to update mtime of $R/gitdir.
On 14-09-11 11:06 PM, Eric Sunshine wrote:
On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud marcn...@xiplink.com wrote:
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
(alias R=$GIT_COMMON_DIR/worktrees/id)
- linked checkouts are supposed to keep its location in $R/gitdir up
to date
On 14-09-21 05:50 AM, Duy Nguyen wrote:
On Sun, Sep 21, 2014 at 10:10 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
Would it make sense for this rule of thumb summary to be presented
first, and then the explanation of that rule after, rather than the
reverse as is currently the case?
On 14-09-21 06:29 AM, Duy Nguyen wrote:
Here we go again. Thanks both for the suggestions.
The documentation looks good to me.
FWIW:
Signed-off-by: Marc Branchaud marcn...@xiplink.com
M.
-- 8 --
Subject: [PATCH] prune: strategies for linked checkouts
(alias R
On 14-09-21 06:43 AM, Duy Nguyen wrote:
And this is the update as suggested in 23/32 [1]
[1] http://thread.gmane.org/gmane.comp.version-control.git/256210/focus=256849
Looks good!
FWIW:
Signed-off-by: Marc Branchaud marcn...@xiplink.com
M.
-- 8 --
Subject: [PATCH] gc
On 14-10-14 03:57 PM, Junio C Hamano wrote:
While use of the --reference option to borrow objects from an
existing local repository of the same project is an effective way to
reduce traffic when cloning a project over the network, it makes the
resulting borrowing repository dependent on the
On 14-10-15 01:29 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
I think things would be more understandable if the option was --dissociate
repository and was an explicit alternative to --reference:
[[--reference | --dissociate] repository]
I'm still not liking
On 14-10-15 05:33 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
On 14-10-15 01:29 PM, Junio C Hamano wrote:
$ git clone \
--reference=/local/pool/linux.git \
--borrow=../my/neighbour/linux-hack.git \
git://git.kernel.org/./linux.git
On 14-10-15 05:50 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
Yes, but we're cloning gko, not the neighbour. Doesn't that mean that the
clone operation won't know about any of the neighbour's refs?
No. --reference (and a natural implementation of --borrow, I
On 13-07-25 09:45 AM, Daniele Segato wrote:
From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001
From: Daniele Segato daniele.seg...@gmail.com
Date: Thu, 25 Jul 2013 15:33:18 +0200
Subject: [PATCH] git-tag man: when to use lightweight or annotated tags
stress the
On 13-07-26 04:46 AM, Daniele Segato wrote:
From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001
From: Daniele Segato daniele.seg...@gmail.com
Date: Thu, 25 Jul 2013 15:33:18 +0200
Subject: [PATCH] git-tag man: when to use lightweight or annotated tags
When sending a patch
of your patch with the fixups I would recommend.
I'm happy with Peff's version.
Reviewed-by: Marc Branchaud marcn...@xiplink.com
(Daniele, don't feel put off because Jonathan I are accepting Peff's text.
If you think it still needs improving please speak up!)
M.
-- 8 --
From
On 13-07-26 01:19 PM, Daniele Segato wrote:
By the way which is your role in the community?
Don't want to be rude, I just don't know who I'm talking about :) the
documentation maintainer?
I'm just a git user and (very) occasional contributor.
There's not much structure to the git community.
On 13-07-29 04:18 AM, Ondřej Bílka wrote:
Hi,
I improved my tool and it catched following additional typos.
As with any big project best way to catch errors is to have automated
checks that catch them ( Other possibility would be to read everything ten
times to get error rate down but
...@seznam.cz
Signed-off-by: Junio C Hamano gits...@pobox.com
Looks good.
Reviewed-by: Marc Branchaud marcn...@xiplink.com
M.
--
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
On 13-07-29 05:15 PM, Øystein Walle wrote:
Signed-off-by: Øystein Walle oys...@gmail.com
---
I thought I'd take part in the typo fixing frenzy :)
I have some other potential typos lines up. Right now the docs refer to both
'filesystem' and 'file system', as well as both 'testsuite' and
This will hopefully avoid questions over which spelling and grammar should
be used. Translators are of course free to create localizations for other
English dialects.
Signed-off-by: Marc Branchaud marcn...@xiplink.com
---
Although I'm Canadian I figured en_CA would be a little too parochial. I
This will hopefully avoid questions over which spelling and grammar should
be used. Translators are of course free to create localizations for other
specific English dialects.
Signed-off-by: Marc Branchaud marcn...@xiplink.com
---
A little less stringent now.
Documentation/CodingGuidelines
On 13-08-01 11:10 AM, Marc Branchaud wrote:
This will hopefully avoid questions over which spelling and grammar should
be used. Translators are of course free to create localizations for other
Oops, I should have removed the word other here.
M.
specific English dialects
This will hopefully avoid questions over which spelling and grammar should
be used. Translators are of course free to create localizations for
specific English dialects.
Signed-off-by: Marc Branchaud marcn...@xiplink.com
---
On 13-08-01 02:21 PM, Junio C Hamano wrote:
Marc Branchaud marcn
On 13-08-02 02:25 AM, Jonathan Nieder wrote:
Junio C Hamano wrote:
Is that accurate? My impression has been:
The documentation liberally mixes US and UK English (en_US/UK)
norms for spelling and grammar, which is somewhat unfortunate.
In an ideal world, it would have been
On 12-08-10 04:09 PM, Junio C Hamano wrote:
Felix Natter fnat...@gmx.net writes:
I have a few questions about this:
As I am coming from large depth is harmful school, I would
recommend
- git repack -a -d -f with large --window with reasonably short
--depth once,
So something like
On 12-09-18 07:46 PM, Paul Mackerras wrote:
On Tue, Sep 18, 2012 at 07:57:54AM +0200, Stefan Haller wrote:
Whenever the diff pane scrolls, highlight the corresponding file in the
file list on the right. For a large commit with many files and long
per-file diffs, this makes it easier to keep
On 12-09-23 01:36 PM, Jens Lehmann wrote:
Am 22.09.2012 22:31, schrieb Junio C Hamano:
Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/git-submodule.sh b/git-submodule.sh
index a7e933e..dfec45d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1108,7 +1108,15 @@ do
On 12-09-27 11:38 PM, Junio C Hamano wrote:
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain git fetch uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach git remote about
On 12-10-15 10:09 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Oct 15, 2012 at 11:14 AM, Angelo Borsotti
angelo.borso...@gmail.com wrote:
Hello,
FWIW we have a lot of lemmings pushing to the same ref all the time at
$work, and while I've seen cases where:
1. Two clients try to push
2.
On 13-06-17 01:52 PM, Matthieu Moy wrote:
The behavior of git push --force is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.
Signed-off-by:
On 13-07-09 04:37 PM, Junio C Hamano wrote:
Johannes Sixt j...@kdbg.org writes:
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean it,
On 12-11-08 04:42 AM, Michael Haggerty wrote:
On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote:
Add a new Python script,
On 12-11-08 07:17 AM, Michael Haggerty wrote:
On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
[...]
I'm glad it's getting some use. Thanks for the feedback.
I'll test it out some more, the issues I've had with it so far in
migrating from the existing script + some custom hacks we
On 12-11-08 11:37 AM, Ævar Arnfjörð Bjarmason wrote:
On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud mbranch...@xiplink.com wrote:
I'd like there to be one list that always gets everything, and the other
lists should get subsets of the everything list.
Since it supports multiple mailing lists
On 12-11-20 07:05 PM, Junio C Hamano wrote:
Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).
[ snip ]
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect
On 12-12-04 07:49 PM, Łukasz Stelmach wrote:
Enable gitk read and write repository specific configuration
file: .git/k if the file exists. To make gitk use the local
file simply create one, e.g. with the touch(1) command.
This is very useful if one uses different views for different
Hi all,
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with git submodule:
$ git submodule init external/openssl
No submodule mapping found in .gitmodules for path ''
(.gitmodules and other aspects of the repo are fine -- the
On 12-12-07 12:54 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with git submodule:
...
Any ideas?
How and why is the IFS set differently only on one of your build
On 12-12-07 02:11 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
On 12-12-07 12:54 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with git
On 12-12-07 03:23 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
sh-setup: protect from exported IFS
Many scripted Porcelains rely on being able to split words at the
default $IFS characters, i.e. SP, HT and LF. If the user exports a
non-default IFS
On 12-12-07 03:23 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
sh-setup: protect from exported IFS
Many scripted Porcelains rely on being able to split words at the
default $IFS characters, i.e. SP, HT and LF. If the user exports a
non-default IFS
Hi all,
Occasionally when doing a fresh clone of a repo, if the clock ticks at just
the wrong time the checked-out files end up with different timestamps.
The effect of this can be that, when make is run in the workdir it'll
decide that some files are out of date and try to rebuild them.
(In
On 12-12-11 04:27 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
Occasionally when doing a fresh clone of a repo, if the clock ticks at just
the wrong time the checked-out files end up with different timestamps.
The effect of this can be that, when make is run
On 12-12-11 05:30 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
My point is that the initial checkout into an empty working directory should
create all files with the same timestamp.
Or, to be a bit more precise, whenever git-checkout *creates* files in the
work dir
On 12-12-12 05:25 PM, Jens Lehmann wrote:
So unless people agree that deinit should also remove the work
tree I'll prepare some patches teaching all git commands to
consistently ignore deinitialized submodules. Opinions?
I agree with Trevor's suggestion that deinit should restore the user to
On 13-03-18 10:25 AM, Jeff King wrote:
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
I've put off implementing remote.default corresponding to
remote.pushdefault, as Jeff suggested in [1], because it's currently
not an itch; apart from the obvious symmetry, I don't
On 12-07-06 03:31 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
On 12-07-05 06:50 PM, Junio C Hamano wrote:
- effective_remote_name is the name of the remote tracked by the current
branch, or is default_remote_name if the current branch doesn't have a
remote
On 12-07-06 03:39 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
If remote.default isn't set, then if someone does
git remote rename origin foo
the default remote will still be origin (modulo the currently-checked-out
branch stuff).
Why?
Erm, actually
On 12-07-06 04:43 PM, Marc Branchaud wrote:
So why change git clone to always set remote.default if the functionality
remains the same either way?
To me it makes a more consistent implementation. Since git remote add sets
remote.default if it's adding the first remote to the repository
On 12-07-11 02:21 PM, Junio C Hamano wrote:
marcn...@xiplink.com writes:
From: Marc Branchaud marcn...@xiplink.com
The code now has a default_remote_name and an effective_remote_name:
- default_remote_name is set by remote.default in the config, or is origin
if remote.default doesn't
On 12-07-11 02:27 PM, Junio C Hamano wrote:
marcn...@xiplink.com writes:
From: Marc Branchaud marcn...@xiplink.com
The rename and rm commands now handle the case where the remote being
changed is the default remote.
handle the case is way underspecified.
Until I peeked the patch, I
On 12-07-11 05:55 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
What about a warning displayed if remote.default is not set? Something
like:
This repository does not have an explicitly configured default
remote. Selecting origin as the default remote
On 12-07-14 02:59 AM, mhag...@alum.mit.edu wrote:
From: Michael Haggerty mhag...@alum.mit.edu
Add a new Python script, contrib/hooks/post-receive-multimail.py, that
can be used to send notification emails describing pushes into a git
repository. This script is derived from
On 13-04-15 02:00 PM, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
I do not think the addition Ram is envisioning in the patch will
prevent you from teaching add to do that. An implemention of such
an addition indeed would most likely use the same --separate-git-dir
mechanism anyway.
On 13-04-15 01:50 PM, Junio C Hamano wrote:
Marc Branchaud mbranch...@xiplink.com writes:
In general I think it is a mistake to overload git clone with the notion of
adding a submodule.
I agree with that principle, but my understanding is that this
effort is not about teaching git clone
On 13-04-15 02:50 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
After that clone or init creates a repository, you still have to
add if you want to make it a submodule to the toplevel.
To me it makes more sense to move the .git directory when the user invokes
git
On 13-04-16 04:13 AM, Ramkumar Ramachandra wrote:
Jeff King wrote:
So there is some information that is per-clone (the objects, the remote
tips), but there is some information that is per-submodule (where our
local branches are, the index, the worktree). I can see why it is
advantageous to
On 13-04-16 04:17 AM, Ramkumar Ramachandra wrote:
Marc Branchaud wrote:
If git add is all about specifying what lives under paths in the worktree,
what's wrong with letting git add go beyond specifying just files?
Syntax aside for the moment, I think a command like
git add git-repo
On 13-04-16 04:21 AM, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
It does not relieve git add (or git submodulea add) from the
responsibility of moving .git directory. It only reduces the need
to do so.
When the user says add and the repository has .git directory in
it, add (or
Signed-off-by: Marc Branchaud marcn...@xiplink.com
---
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
M.
Documentation/RelNotes/1.8.3.txt | 145 +++
1 file changed, 72
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
* git bundle did not like a bundle created using a commit without
On 13-05-01 04:24 AM, Lukas Fleischer wrote:
On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable
On 13-05-01 06:31 AM, Thomas Adam wrote:
On 1 May 2013 11:12, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
remove '~0', and we can remove
On 13-09-24 03:51 AM, Jeff King wrote:
On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
I think it would be preferable if --prune would *not* affect tags, and
if there were an extra option like --prune-tags that would have to be
used explicitly to cause tags to be pruned.
On 13-09-27 02:52 PM, Jonathan Nieder wrote:
The latest maintenance release Git v1.8.4.1 is now available.
The release tarballs are found at:
http://alioth.debian.org/~jrnieder-guest/git/
and their SHA-1 checksums are:
49004a8dfcbb7c0848147737d9877fd7313a42ec git-1.8.4.1.tar.gz
On 13-09-29 12:29 AM, Michael Haggerty wrote:
On 09/28/2013 11:42 PM, Johan Herland wrote:
On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
[...]
* How would somebody (e.g., an interim maintainer) suck down tags from
a project into his own refs/tags/*
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
Why would there be ambiguity warnings? The fetch command shouldn't issue any
warnings, since all the remotes' names get safely tucked away in distinct
namespaces.
Are we talking about DWIM warnings
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
Consider that I have in my Linux kernel tree:
- a remote branch corresponding to Linus' master tree
- multiple remote branches corresponding to Linux stable
On 13-09-30 06:44 PM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
Again, in the cases where there is actually a SHA1 conflict between all
possible tags that match a tag short-end then listing them and asking the
user to be more
On 13-09-30 11:28 PM, Nicolas Pitre wrote:
But with my proposal, you'd get a message saying that the tag baz is
ambigous, and that you'd have to use either libfoo/baz or
libbar/baz.
Yes, and that's good. I agree with your proposal. Sorry if that wasn't
clear.
M.
--
To
On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:
The next and prev buttons are lacking consistency and logic. For RTL
languages previous is almost always on the left, and next on the right. The
words are contradictory, next actually goes to backwards chronologically,
and prev goes
On 13-10-08 03:36 PM, Jonathan Nieder wrote:
In a branchy history, it is possible for the next matching commit to
actually be newer.
Chronologically, yes.
Gitk will often display a history like this (here the numbers represent
commit dates, so 1 is the oldest commit, and I've rotated this 90
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that is almost always backwards in time. Renaming next to older
and prev to newer makes it clear where the buttons will take the user.
---
(Apologies to Lucas
On 13-10-30 08:47 AM, Nicolas Cornu wrote:
This is useful on all our repos, every times, as we put a tag per day.
If the HEAD didn't move during 150 days, we got 150 tags.
So, it depends, maybe can I put it as an option in Edit Preferences?
Eek, even with a scrollbar, 150 tags seems like a
On 13-10-30 10:49 AM, Nicolas Cornu wrote:
2013/10/30 Marc Branchaud marcn...@xiplink.com:
On 13-10-30 08:47 AM, Nicolas Cornu wrote:
This is useful on all our repos, every times, as we put a tag per day.
If the HEAD didn't move during 150 days, we got 150 tags.
So, it depends, maybe can I
On 13-10-31 05:05 AM, Paul Mackerras wrote:
On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote:
This is useful on all our repos, every times, as we put a tag per day.
If the HEAD didn't move during 150 days, we got 150 tags.
Here is a patch that I did some time ago but have never
On 13-11-06 07:01 PM, Junio C Hamano wrote:
There is a proposed rewording of advice message from git push
patch, which is tentatively queued near the tip of 'pu' for now; it
would be nice to get a few more sets of eyeballs. I am not sure if
we should merge it before the 1.8.5 final, yet (we
On 13-11-08 01:02 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jonathan Nieder jrnie...@gmail.com writes:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
Yes,
On 13-11-11 12:02 PM, Junio C Hamano wrote:
Is everybody happy with this version?
Looks good.
M.
--
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
On 13-11-13 06:07 PM, Junio C Hamano wrote:
A release candidate Git v1.8.5-rc2 is now available for testing
at the usual places.
[ snip ]
Updates since v1.8.4
Foreign interfaces, subsystems and ports.
* git-svn used with SVN 1.8.0 when talking over https://
---
Mostly just tweaks, although I did change the foo^{tag} description a lot.
M.
Documentation/RelNotes/1.8.5.txt | 158 ---
1 file changed, 80 insertions(+), 78 deletions(-)
diff --git a/Documentation/RelNotes/1.8.5.txt
On 13-11-18 01:49 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com writes:
Foreign interfaces, subsystems and ports.
* git-svn used with SVN 1.8.0 when talking over https:// connection
dumped core due to a bug in the serf library
On 13-11-18 01:42 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
Mostly just tweaks, although I did change the foo^{tag} description a lot.
Thanks. It is surprising that one can make so many typoes in a
single document ;-)
@@ -55,7 +55,7 @@ Foreign interfaces
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that is almost always backwards in time. Replacing the text with arrows
makes it clear where the buttons will take the user.
Signed-off-by: Marc Branchaud marcn
1 - 100 of 218 matches
Mail list logo
