Re: Feature request: fetch --prune by default
Am 7/19/2012 23:20, schrieb Alexey Muranov: > On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: > >> On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov >> wrote: >> >> [...] >>> I do not still understand very well some aspects of Git, like the >>> exact purpose of "remote tracking branches" (are they for pull or >>> for push?), so i may be wrong. >> This is wery well explained in the Pro Git book, for instance. And in >> numerous blog posts etc. > > I have read the Pro Gut book and numerous blog posts, but i keep > forgetting the explanation because it does not make much sense to me: > > "Tracking branches are local branches that have a direct relationship > to a remote branch. If you’re on a tracking branch and type git push, > Git automatically knows which server and branch to push to. Also, > running git pull while on one of these branches fetches all the remote > references and then automatically merges in the corresponding remote > branch." etc. Note the difference between "tracking branch" and "remote tracking branch"! The "remote tracking branches" are the refs in the refs/remotes/ hierarchy. The "tracking branches" are your own local branches that you have created with 'git branch topic thatremote/topic' (or perhaps 'git checkout -b'). The paragraph talks about the latter. -- Hannes -- 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
Re: Feature request: fetch --prune by default
On 20 Jul 2012, at 09:11, Johannes Sixt wrote: > Am 7/19/2012 23:20, schrieb Alexey Muranov: >> On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote: >> >>> On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov >>> wrote: >>> >>> [...] I do not still understand very well some aspects of Git, like the exact purpose of "remote tracking branches" (are they for pull or for push?), so i may be wrong. >>> This is wery well explained in the Pro Git book, for instance. And in >>> numerous blog posts etc. >> >> I have read the Pro Gut book and numerous blog posts, but i keep >> forgetting the explanation because it does not make much sense to me: >> >> "Tracking branches are local branches that have a direct relationship >> to a remote branch. If you’re on a tracking branch and type git push, >> Git automatically knows which server and branch to push to. Also, >> running git pull while on one of these branches fetches all the remote >> references and then automatically merges in the corresponding remote >> branch." etc. > > Note the difference between "tracking branch" and "remote tracking > branch"! The "remote tracking branches" are the refs in the refs/remotes/ > hierarchy. The "tracking branches" are your own local branches that you > have created with 'git branch topic thatremote/topic' (or perhaps 'git > checkout -b'). The paragraph talks about the latter. Hannes, thanks for the explanation, so i was confused once again. Various blog posts do not make the terminology clear, for example http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html sais that there are only "two types of branches: local, and remote-tracking", while i think it depends on perspective. There are in fact 1. remote, 2. remote-tracking (which are local!), 3. truly local: a) which are tracking some remote-tracking(!) branches, b) and which are not tracking. I think i was also misguided by Konstantin, who wrote that "you create a remote tracking branch when you intend to actually *develop* something on that branch" :). -Alexey.-- 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
Re: [PATCH 4/7] git-rebase--interactive.sh: look up subject in add_pick_line
Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
> @@ -814,7 +814,8 @@ add_pick_line () {
> else
> comment_out=
> fi
> - printf '%s\n' "${comment_out}pick $1 $2" >>"$todo"
> + line=$(git rev-list -1 --pretty=oneline --abbrev-commit --abbrev=7 $1)
> + printf '%s\n' "${comment_out}pick $line" >>"$todo"
I don't like this. On Windows, rebase -i is already slow, and these extra
processes will make it even slower.
> + git rev-list $revisions --reverse --left-right --topo-order |
> sed -n "s/^>//p" |
> - while read -r shortsha1 rest
> + while read -r sha1
> do
> - sha1=$(git rev-parse $shortsha1)
> if test -z "$rebase_root"
...
> - add_pick_line $shortsha1 "$rest"
> + add_pick_line $sha1
> fi
This is 'rebase -p' case, and you trade the new processes for some old ones.
> + git rev-list $revisions --reverse --left-right --topo-order \
> + --no-merges --cherry-pick |
> sed -n "s/^>//p" |
> - while read -r shortsha1 rest
> + while read -r sha1
> do
> - add_pick_line $shortsha1 "$rest"
> + add_pick_line $sha1
> done
But in the regulare case, you don't; the processes are really new.
Anything that can be done about this? Perhaps the rev-list call can
generate all of the full SHA1, the short SHA1, and the subject with a
--pretty format?
-- Hannes
--
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
Re: [PATCH 7/7] rebase (without -p): correctly calculate patches to rebase
Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
> diff --git a/git-rebase--am.sh b/git-rebase--am.sh
> index 37c1b23..fe3fdd1 100644
> --- a/git-rebase--am.sh
> +++ b/git-rebase--am.sh
> @@ -16,11 +16,9 @@ skip)
> ;;
> esac
>
> -test -n "$rebase_root" && root_flag=--root
> test -n "$keep_empty" && git_am_opt="$git_am_opt --keep-empty"
> -git format-patch -k --stdout --full-index --ignore-if-in-upstream \
> - --src-prefix=a/ --dst-prefix=b/ \
> - --no-renames $root_flag "$revisions" |
> +generate_revisions |
> +sed -e 's/\([0-9a-f]\{40\}\)/From \1 Mon Sep 17 00:00:00 2001/' |
> git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" &&
> move_to_original_branch
Just curious (as all tests pass): What does this do? It looks like
format-patch is not called anymore and git-am sees only SHA1s. Does it
force git-am to cherry-pick the patches?
-- Hannes
--
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
Re: [PATCH 1/3] retain reflogs for deleted refs
On 07/19/2012 11:33 PM, Jeff King wrote:
[...]
This cannot be done by simply leaving the reflog files in
place. The ref namespace does not allow D/F conflicts, so a
ref "foo" would block the creation of another ref "foo/bar",
and vice versa. This limitation is acceptable for two refs
to exist simultaneously, but should not have an impact if
one of the refs is deleted.
This is a great feature.
This patch moves reflog entries into a special "graveyard"
namespace, and appends a tilde (~) character, which is
not allowed in a valid ref name. This means that the deleted
reflogs of these refs:
refs/heads/a
refs/heads/a/b
refs/heads/a/b/c
will be stored in:
logs/graveyard/refs/heads/a~
logs/graveyard/refs/heads/a/b~
logs/graveyard/refs/heads/a/b/c~
Putting them in the graveyard namespace ensures they will
not conflict with live refs, and the tilde prevents D/F
conflicts within the graveyard namespace.
I agree with Junio that long-term, it would be nice to allow references
"foo" and "foo/bar" to exist simultaneously. To get there, we would
have to redesign the mapping between reference names and the filenames
used for the references and for the reflogs.
The easiest thing would be to mark files and directories differently;
something like
$GIT_DIR/{,logs/}refs/heads/a/b/c~
or
$GIT_DIR/{,logs/}refs/heads~/a~/b~/c
i.e., munging either directory or file names to strings that are illegal
in refnames such that it is unambiguous from the name whether a path is
a file or directory.
And *if* we did that, then we wouldn't need a separate "graveyard"
namespace, would we? The reflogs for dead references could live among
those for living references.
Therefore, I think it would be good if we would choose a convention now
for dead reflogs that is compatible with this hoped-for future.
The first convention, "logs/refs/heads/a/b/c~" is not usable because a
reflog for a dead reference with this name would conflict with a reflog
for a live reference "heads/a" or "heads/a/b" that uses the current
filename convention.
But the second convention, "logs/refs/heads~/a~/b~/c, cannot conflict
with current reflog files. And it would be a step towards allowing
"foo" and "foo/bar" at the same time. What do you think about using a
convention like this instead of the one that you proposed?
Another minor concern is the choice of trailing tilde in the file or
directory names. Given that emacs creates backup files by appending a
tilde to the filename, (1) it would be easy to inadvertently create such
files, which git might try to interpret as reflogs and (2) there might
be tools that innately "know" to skip such files in their processing.
ack-grep, a replacement for grep, is an example that springs to mind. I
know that I have written backup scripts that ignore files matching "*~",
and a garbage-removal script that removes files matching "*~". Probably
it is less precarious to name directories rather than files with
trailing tildes, but either one could be a surprise for sysadmins.
Other possibilities (according to git-check-ref-format(1)):
refs/.heads/.a/.b/c
refs/heads./a./b./c (problematic on some Windows filesystems?)
refs/heads../a../b../c
refs/heads~dir/a~dir/b~dir/c (or some other suffix)
refs/heads..a..b..c (not recommended because it flattens directory
hierarchy)
The implementation is fairly straightforward, but it's worth
noting a few things:
1. Updates to "logs/graveyard/refs/heads/foo~" happen
under the ref-lock for "refs/heads/foo". So deletion
still takes a single lock, and anyone touching the
reflog directly needs to reverse the transformation to
find the correct lockfile.
This should be documented in the code.
2. We append entries to the graveyard reflog rather than
simply renaming the file into place. This means that
if you create and delete a branch repeatedly, the
graveyard will contain the concatenation of all
iterations.
Good.
3. We do not resurrect dead entries when a new ref is
created with the same name. However, it would be
possible to build an "undelete" feature on top of this
if one was so inclined.
Nice prospect.
[...]> diff --git a/refs.c b/refs.c
index da74a2b..553de77 100644
--- a/refs.c
+++ b/refs.c
[...]
@@ -2552,3 +2553,63 @@ char *shorten_unambiguous_ref(const char *refname, int
strict)
free(short_name);
return xstrdup(refname);
}
+
+char *refname_to_graveyard_reflog(const char *ref)
+{
+ return git_path("logs/graveyard/%s~", ref);
+}
+
+char *graveyard_reflog_to_refname(const char *log)
+{
+ static struct strbuf buf = STRBUF_INIT;
+
+ if (!prefixcmp(log, "graveyard/"))
+ log += 10;
+
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, log);
+ if (buf.len > 0 && buf.buf[buf.len-1] == '~')
+ strbuf_setlen(&buf, buf.len - 1);
+
+ retur
Re: [RFC] Add a new email notification script to "contrib"
On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote: 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. [...] Thanks to everybody for your feedback. I will try to incorporate it in a new version of the script, which I will put forward as a replacement for contrib/hooks/post-receive-email rather than as an alternative. But I have very little open-sourcing time these days, and will be on vacation next week, so please be patient (or feel free to lend a hand if you are so inclined). Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [ANNOUNCE] Sharness - Test library derived from Git
On Tue, Jul 17, 2012 at 8:31 PM, Ævar Arnfjörð Bjarmason wrote: > Nice, I thought about doing something like this myself but never had the time. Thanks. Took quite some time to take out the Git-specific functionality. And there's still a lot of room for improvement. > Perhaps to avoid duplication we could move to this and keep > Git-specific function in some other file. That would be fantastic! From a technical point of view, it would make a lot of sense to join forces here. How do you think would Sharness fit into the Git project? Is adding it as an external dependency an option? Let's share some ideas before getting to it. > Do you think that would be sensible, and would you be willing to > submit patches for that? While I haven't touched the names of the test functions, I renamed most of the global shell variables, e.g. GIT_TEST_OPTS to TEST_OPTS and TEST_DIRECTORY to SHARNESS_TEST_DIRECTORY. That might be a (minor) problem. As for the patches: absolutely. I'd really love to give something back to Git. -Mathias -- 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
Re: [ANNOUNCE] Sharness - Test library derived from Git
Mathias Lafeldt writes: > On Tue, Jul 17, 2012 at 8:31 PM, Ævar Arnfjörð Bjarmason > wrote: > >> Perhaps to avoid duplication we could move to this and keep >> Git-specific function in some other file. > > That would be fantastic! From a technical point of view, it would make > a lot of sense to join forces here. Seems to be a reasonable goal, yes. The test harness in Git keeps improving, and Sharness is likely to improve also, it would be a pity to have them diverge and not benefit from each other. > How do you think would Sharness fit into the Git project? Is adding it > as an external dependency an option? It would be nice if the code sharing did not result in extra pain for users and testers, so "external dependency" in the sense "not included in git.git and ask the user to install it" is IMHO a bad idea. Increasing the effort needed to run the testsuite means more people will give up before running it :-(. OTOH, having it leave in a subdirectory (e.g. $git/t/Sharness/), and synchronize with stg like subtree merge would be nice for the user. We already have something similar for gitk and git-gui, except that the synchronization is normally one way (subprojects merged into Git, but merging back changes that were made in git.git in these subprojects is more painful). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Fri, Jul 20, 2012 at 12:23:12AM +0200, Alexey Muranov wrote: > i have no idea about Git source and little idea of how it is working > internally, but reading through your message i wonder: wouldn't it be > a good idea to timestamp the dead reflogs ? Each individual entry in the reflog has its own timestamp, and the entries are expired individually over time as "git gc" is run. Or did you mean something else? -Peff -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On 20 Jul 2012, at 16:26, Jeff King wrote: > On Fri, Jul 20, 2012 at 12:23:12AM +0200, Alexey Muranov wrote: > >> i have no idea about Git source and little idea of how it is working >> internally, but reading through your message i wonder: wouldn't it be >> a good idea to timestamp the dead reflogs ? > > Each individual entry in the reflog has its own timestamp, and the > entries are expired individually over time as "git gc" is run. Or did > you mean something else? Yes, sorry, i was not clear, i meant to put dead reflogs into subdirectories -mm-dd, or maybe -mm-dd-hhmmss. -Alexey.-- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Thu, Jul 19, 2012 at 03:36:09PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Only one test needed to be updated; t7701 tries to create > > unreachable objects by deleting branches. Of course that no > > longer works, which is the intent of this patch. The test > > now works around it by removing the graveyard logs. > > I think the work-around indicates the need for regular users to be > able to also discover, prune and delete these logs. Do we have > "prune reflog for _this_ ref (or these refs), removing entries that > are older than this threshold"? If so the codepath would need to > know about the graveyard and the implementation detail of the tilde > suffix so that the end users do not need to know about them. We do have it: "git reflog expire --expire=now deleted-branch" is the right way to do it. Unfortunately, it does not work with my patch. The dwim_log correctly notes that a reflog exists (because it checks that the "graveyard" version of the ref exists), but then expire_reflog does not correctly fallback when opening the log (it usually has to do the _reverse_ translation, because it gets the graveyard log name from for_each_reflog, and has to find the correct lock). I'll fix it in my re-roll, and then have t7701 use it. > I like the general direction. Perhaps a long distant future > direction could be to also use the same trick in the ref namespace > so that we can have 'next' branch itself, and 'next/foo', 'next/bar' > forks that are based on the 'next' branch at the same time (it > obviously is a totally unrelated topic)? I would love that, as it would mean we could simply leave the reflogs in place without having a separate graveyard namespace. Which means there wouldn't need to be any reflog-specific translation at all, and bugs like the one above wouldn't exist. But it would mean that you cannot naively run echo $sha1 >.git/refs/heads/foo anymore. I suspect that the packed-refs conversion rooted out many scripts that did not use update-ref and rev-parse to access refs, but the above does still work today. So I suspect there would be some fallout. Not to mention that older versions of git would be completely broken, which would mean we need a lengthy deprecation period while everybody upgrades to versions of git that support the reading side. -Peff -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Fri, Jul 20, 2012 at 10:43:37AM -0400, Jeff King wrote: > > I think the work-around indicates the need for regular users to be > > able to also discover, prune and delete these logs. Do we have > > "prune reflog for _this_ ref (or these refs), removing entries that > > are older than this threshold"? If so the codepath would need to > > know about the graveyard and the implementation detail of the tilde > > suffix so that the end users do not need to know about them. > > We do have it: "git reflog expire --expire=now deleted-branch" is the > right way to do it. Unfortunately, it does not work with my patch. The > dwim_log correctly notes that a reflog exists (because it checks that > the "graveyard" version of the ref exists), but then expire_reflog does > not correctly fallback when opening the log (it usually has to do the > _reverse_ translation, because it gets the graveyard log name from > for_each_reflog, and has to find the correct lock). > > I'll fix it in my re-roll, and then have t7701 use it. I noticed I ignored the "discover" and "delete" parts of your paragraph. As far as deletion goes, I think we can ignore it; expiring all entries is equivalent. Discovery is harder. Certainly these should not show up in normal ref-listing output. I'd be content to leave them slightly hidden as a first step, and people who know they are looking for the pre-deletion contents of the "foo" branch can access it by name. Probably a second step would be a fancier interface to help with listing and resurrecting dead branches, possibly including branch config. In other words, I want to focus on getting the ref-level plumbing right, and then we can care about the porcelain later. -Peff -- 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
pushing branches
Hi, How can I push a working branch to github inside it? E.g: # On master: $ git checkout -b feature-work # On feature-work # vi, hack, commit, ready to push $ git push origin master # here I expected it would working pushing my commits to a feature-work branch in github. Or if I omit master it gives me a [rejected] error. Everything up-to-date. $ git checkout master $ git push origin feature-work # Now the branch is pushed. Thanks, -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
Jeff King writes: > I noticed I ignored the "discover" and "delete" parts of your paragraph. > As far as deletion goes, I think we can ignore it; expiring all entries > is equivalent. > ... > In other words, I want to focus on getting the ref-level plumbing right, > and then we can care about the porcelain later. Yeah, I agree that is a reasonable way forward. for-each-ref with a new option (--include-dead or something) can wait. -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
Jeff King writes: > But it would mean that you cannot naively run > > echo $sha1 >.git/refs/heads/foo > > anymore. I suspect that the packed-refs conversion rooted out many > scripts that did not use update-ref and rev-parse to access refs, but > the above does still work today. So I suspect there would be some > fallout. Not to mention that older versions of git would be completely > broken, which would mean we need a lengthy deprecation period while > everybody upgrades to versions of git that support the reading side. We have that "core.repositoryversion" thing, so we could treat it just like "update-index --index-version 4" to make it a "flag day event for each repository, on the day of end-user's choice". -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Fri, Jul 20, 2012 at 11:49:07AM +0200, Michael Haggerty wrote:
> >This patch moves reflog entries into a special "graveyard"
> >namespace, and appends a tilde (~) character, which is
> >not allowed in a valid ref name. This means that the deleted
> >reflogs of these refs:
> >
> >refs/heads/a
> >refs/heads/a/b
> >refs/heads/a/b/c
> >
> >will be stored in:
> >
> >logs/graveyard/refs/heads/a~
> >logs/graveyard/refs/heads/a/b~
> >logs/graveyard/refs/heads/a/b/c~
> >
> >Putting them in the graveyard namespace ensures they will
> >not conflict with live refs, and the tilde prevents D/F
> >conflicts within the graveyard namespace.
>
> I agree with Junio that long-term, it would be nice to allow
> references "foo" and "foo/bar" to exist simultaneously. To get
> there, we would have to redesign the mapping between reference names
> and the filenames used for the references and for the reflogs.
Yes, I would really like that, as it could make the alternate namespace
go away, which is the source of about half the code in my patches (i.e.,
we would only need to loosen the reflog reading code to handle reflogs
that do not have a matching ref).
But I fear that the fallouts from that will be much, much larger. Even
with just this change, older versions of git will be slightly unhappy
(e.g., you will get some extra warnings during fsck and reflog
expiration about these reflogs). But changing the on-disk representation
of the refs namespace will mean a totally new representation of locking.
That's going to break old versions of git completely, and possibly even
some user scripts.
> The easiest thing would be to mark files and directories differently;
> something like
>
> $GIT_DIR/{,logs/}refs/heads/a/b/c~
> [...]
> The first convention, "logs/refs/heads/a/b/c~" is not usable because
> a reflog for a dead reference with this name would conflict with a
> reflog for a live reference "heads/a" or "heads/a/b" that uses the
> current filename convention.
Right. That's what I started with, then created the graveyard hierarchy
to avoid conflicts between the "old" namespace (that cannot handle D/F
conflicts) and the "new" one (that can, because it represents files and
directories differently).
> or
>
> $GIT_DIR/{,logs/}refs/heads~/a~/b~/c
>
> i.e., munging either directory or file names to strings that are
> illegal in refnames such that it is unambiguous from the name whether
> a path is a file or directory.
This one can have conflicts in the opposite direction if you don't have
any directories. E.g., you have $GIT_DIR/foo, a deleted ref, which has
no tildes because it has no directories in the path. But you want to
create foo/bar under the "old" system, which cannot happen (under the
new system, it is fine, but the point of this exercise is to overlay the
old and new systems).
That may be an OK tradeoff. We are restrictive in what goes into the
top-level. Although I notice that you did not mark "refs" in the above
example. So you could have the same problem with "refs/stash", for
example. Again, though, we don't tend to have arbitrary data at the
top-level (and I think refs/stash gets special cased in a couple places
already). So it might be an acceptable limitation.
If we want to be pedantic, my patch causes conflicts for top-level refs
called "graveyard" (although I know we have talked about restricting
top-level refs to [A-Z_-], I don't recall if that has actually
happened).
> And *if* we did that, then we wouldn't need a separate "graveyard"
> namespace, would we? The reflogs for dead references could live
> among those for living references.
Right, assuming the limitation above is OK. But note that it doesn't
really save us any code. We still have to convert between refnames and
graveyard versions. _Eventually_ if the refnames were all converted,
that code could go away.
> But the second convention, "logs/refs/heads~/a~/b~/c, cannot conflict
> with current reflog files. And it would be a step towards allowing
> "foo" and "foo/bar" at the same time. What do you think about using
> a convention like this instead of the one that you proposed?
I think it's reasonable. As I said, it doesn't save any code _now_, but since
I am pulling a convention out of thin air, it might as well be one that
has a possibility of converging in the future (all other things being
equal, of course; I do find marking the directories a little uglier to
read, but that is mostly because of the tilde).
> Another minor concern is the choice of trailing tilde in the file or
> directory names. Given that emacs creates backup files by appending
> a tilde to the filename, (1) it would be easy to inadvertently create
> such files, which git might try to interpret as reflogs and (2) there
> might be tools that innately "know" to skip such files in their
> processing. ack-grep, a replacement for grep, is an example that
> springs to mind.
The use of "~" for backup files was actually something that made me
Re: pushing branches
Thiago Farina writes: > How can I push a working branch to github inside it? > > E.g: > > # On master: > $ git checkout -b feature-work > > # On feature-work > # vi, hack, commit, ready to push > $ git push origin master # here I expected it would working pushing my "git push origin master" is a short-hand for "git push origin refs/heads/master:refs/heads/master" to update their master branch with what you have in your master branch. See output from $ git push --help for details. I think you are trying to update, while on your feature-work branch, their master with your feature-work branch (or more generally, the current HEAD), so $ git push origin HEAD:master is perhaps what you are looking for? -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 8:26 AM, Thiago Farina wrote: > Hi, > > How can I push a working branch to github inside it? > > E.g: > > # On master: > $ git checkout -b feature-work > > # On feature-work > # vi, hack, commit, ready to push > $ git push origin master # here I expected it would working pushing my > commits to a feature-work branch in github. Or if I omit master it > gives me a [rejected] error. > Everything up-to-date. > > $ git checkout master > $ git push origin feature-work # Now the branch is pushed. ??? I must be missing something. It looks like the reason it didn't push feature-work the first time is because you told it to push master instead. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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
Re: [PATCH 4/7] git-rebase--interactive.sh: look up subject in add_pick_line
Thanks for reviewing.
On Fri, Jul 20, 2012 at 1:14 AM, Johannes Sixt wrote:
> Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
>> @@ -814,7 +814,8 @@ add_pick_line () {
>> else
>> comment_out=
>> fi
>> - printf '%s\n' "${comment_out}pick $1 $2" >>"$todo"
>> + line=$(git rev-list -1 --pretty=oneline --abbrev-commit --abbrev=7 $1)
>> + printf '%s\n' "${comment_out}pick $line" >>"$todo"
>
> I don't like this. On Windows, rebase -i is already slow, and these extra
> processes will make it even slower.
I don't like it either :-(.
> Anything that can be done about this? Perhaps the rev-list call can
> generate all of the full SHA1, the short SHA1, and the subject with a
> --pretty format?
After patch 7/7, cherry is used instead of rev-list. Ideally, I would
have liked to teach "git rev-list --cherry-pick" to somehow use a
just like cherry does, but I couldn't think of a generic way
of doing that (in this case, we want to say something like "range
a..b, but drop commits that are equivalent to any in b..c"). I
actually don't remember if I gave up because I couldn't think of a
sensible way of specifying ranges like that, or if I just ran out of
time (not familiar with the revision-walking code). Now it seems to me
that something like "git rev-list a..b --not-cherry-picks b..c" makes
sense, but maybe it's just too specific and we should just support the
limited (no pun intended) case we need to emulate "git cherry", i.e.
something like "git rev-list --cherry-with-limit=a c...b". Feedback
appreciated.
Martin
--
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
Re: pushing branches
On Fri, 20 Jul 2012 12:26:09 -0300 Thiago Farina wrote: > How can I push a working branch to github inside it? > > E.g: > > # On master: > $ git checkout -b feature-work > > # On feature-work > # vi, hack, commit, ready to push > $ git push origin master # here I expected it would working pushing my > commits to a feature-work branch in github. Or if I omit master it > gives me a [rejected] error. $ git push origin master means "update the branch 'master' in the remote repository with the contents of the branch 'master' in the local repository". Read the "git push" manual. > $ git checkout master > $ git push origin feature-work # Now the branch is pushed. Sure, but it has nothing to do with the previous checkout command: you just told Git to push the contents of your local branch "feature-work" to a remote branch "feature-work" which presumably does not exist and gets created as a result of your push. If you want to update the remote "master" branch with the contents of your local "feature-work" branch, do $ git push origin feature-work:master As stated below, you should really read the git push manual and reading through the appropriate sections of the http://git-scm.com/book is also highly advised. Also consider reading about the "push.default" configuration variable in the git config manual--this might save you from scratching your head when you try to do simple `git push origin` without specifying any branches: here again your expectation might differ from the Git defaults. -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 12:46 PM, Junio C Hamano wrote: > Thiago Farina writes: > >> How can I push a working branch to github inside it? >> >> E.g: >> >> # On master: >> $ git checkout -b feature-work >> >> # On feature-work >> # vi, hack, commit, ready to push >> $ git push origin master # here I expected it would working pushing my > > "git push origin master" is a short-hand for "git push origin > refs/heads/master:refs/heads/master" to update their master branch > with what you have in your master branch. > > See output from > > $ git push --help > > for details. > > I think you are trying to update, while on your feature-work branch, > their master with your feature-work branch (or more generally, the > current HEAD), so > > $ git push origin HEAD:master > > is perhaps what you are looking for? What I'm looking for is to upload/create the remote branch in github from inside my local branch, without having to checkout master in order to do so. -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Fri, Jul 20, 2012 at 08:42:57AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would mean that you cannot naively run
> >
> > echo $sha1 >.git/refs/heads/foo
> >
> > anymore. I suspect that the packed-refs conversion rooted out many
> > scripts that did not use update-ref and rev-parse to access refs, but
> > the above does still work today. So I suspect there would be some
> > fallout. Not to mention that older versions of git would be completely
> > broken, which would mean we need a lengthy deprecation period while
> > everybody upgrades to versions of git that support the reading side.
>
> We have that "core.repositoryversion" thing, so we could treat it
> just like "update-index --index-version 4" to make it a "flag day
> event for each repository, on the day of end-user's choice".
True. The code to handle both cases would be pretty nasty, though,
mostly because we do not isolate the filesystem calls at all right now
(i.e., there are a lot of calls to git_path("logs/%s", refname) in the
code. Which is probably not too bad, but there are a lot of implicit
reverse-conversions (e.g., walking the hierarchy and assuming that the
path you find is a refname).
If we are seriously considering doing this for the full refs namespace
anytime soon, then I'd be tempted to hold off the reflog graveyard until
then. The code would be a lot simpler and less error-prone if we
didn't have to convert between the namespaces (you would simply not get
the reflog retention behavior in the old repositoryformatversion).
-Peff
--
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
Re: pushing branches
Thiago Farina writes: > $ git push origin master # here I expected it would working pushing my > commits to a feature-work branch in github. Or if I omit master it > gives me a [rejected] error. > Everything up-to-date. If your workflow is to push one branch at a time, and you have the same naming locally and remotely (i.e. your local branch feature-work should be pushed as feature-work on github), then you probably want to set the variable 'push.default' to either 'current', 'upstream' or 'simple' if you use the last version of Git. Read about it there: http://git-scm.com/docs/git-config (search push.default) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: [PATCH 2/3] teach sha1_name to look in graveyard reflogs
On Thu, Jul 19, 2012 at 03:39:24PM -0700, Junio C Hamano wrote:
> > Similarly, for_each_reflog_ent learns to fallback to
> > graveyard refs, which allows the reflog walker to work.
> > However, this is slightly less friendly, as the revision
> > parser expects the matching ref to exist before it realizes
> > that we are interested in the reflog. Therefore you must use
> > "git log -g deleted@{1}" insted of "git log -g deleted" to
> > walk a deleted reflog.
>
> This may or may not be related, but I vaguely recall that "log -g"
> traversal hack had a corner case where the walking stops prematurely
> upon seeing a gap (or creation/deletion that has 0{40})? Do you
> recall if we have ever dealt with that?
>From my tests, I think it is probably still broken (if you do a delete,
create, delete sequence on a branch and then walk the reflog, it stops
prematurely at the 0{40} sha1).
But what _should_ it show for such an entry? There is no commit to show
in the reflog walker, but it would still be nice to say "BTW, there was
a deletion even here". Obviously just skipping it and showing the next
entry would be better than the current behavior of stopping the
traversal, but I feel like there must be some better behavior.
-Peff
--
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
Re: [PATCH 7/7] rebase (without -p): correctly calculate patches to rebase
On Fri, Jul 20, 2012 at 1:18 AM, Johannes Sixt wrote:
> Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
>> diff --git a/git-rebase--am.sh b/git-rebase--am.sh
>> index 37c1b23..fe3fdd1 100644
>> --- a/git-rebase--am.sh
>> +++ b/git-rebase--am.sh
>> @@ -16,11 +16,9 @@ skip)
>> ;;
>> esac
>>
>> -test -n "$rebase_root" && root_flag=--root
>> test -n "$keep_empty" && git_am_opt="$git_am_opt --keep-empty"
>> -git format-patch -k --stdout --full-index --ignore-if-in-upstream \
>> - --src-prefix=a/ --dst-prefix=b/ \
>> - --no-renames $root_flag "$revisions" |
>> +generate_revisions |
>> +sed -e 's/\([0-9a-f]\{40\}\)/From \1 Mon Sep 17 00:00:00 2001/' |
>> git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" &&
>> move_to_original_branch
>
> Just curious (as all tests pass): What does this do? It looks like
> format-patch is not called anymore and git-am sees only SHA1s. Does it
> force git-am to cherry-pick the patches?
That probably deserves to be mentioned in the commit message. Or maybe
in as a comment in the code. Either way, since 0fbb95d (am: don't call
mailinfo if $rebasing, 2012-06-26), 'git am --rebasing' never looks at
anything but the sha1, so most of the output from 'git format-patch'
is currently ignored. It doesn't do cherry-pick, though, but runs 'git
diff-tree' and other commands and then feeds the result to 'git
apply', just like a regular 'git am' invocation would.
Martin
--
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
Re: [PATCH 1/3] retain reflogs for deleted refs
Am 20.07.2012 11:49, schrieb Michael Haggerty: > Other possibilities (according to git-check-ref-format(1)): > > refs/.heads/.a/.b/c > refs/heads./a./b./c (problematic on some Windows filesystems?) Yes. Probably all filesystems. > refs/heads../a../b../c Same here. > refs/heads~dir/a~dir/b~dir/c (or some other suffix) > refs/heads..a..b..c (not recommended because it flattens directory > hierarchy) -- Hannes -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
Am 20.07.2012 17:44, schrieb Jeff King: > So I think a suffix like ":d" is probably the least horrible. Not so. It does not work on Windows :-( in the expected way. Trying to open a file with a colon-separated suffix either opens a resource fork on NTFS or fails with "invalid path". -- Hannes -- 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
Re: [PATCH 1/3] retain reflogs for deleted refs
On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote: > Am 20.07.2012 17:44, schrieb Jeff King: > > So I think a suffix like ":d" is probably the least horrible. > > Not so. It does not work on Windows :-( in the expected way. Trying to > open a file with a colon-separated suffix either opens a resource fork > on NTFS or fails with "invalid path". Bleh. It seems that we did too good a job in coming up with a list of disallowed ref characters; they really are things you don't want in your filenames at all. :) -Peff -- 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
git with large files...
I use git for many things, but I am trying to work out the workflow to use git for deployment. I have a wordpress site that i need to track multiple branches of and it has many many resource files, images, video, etc... how can i streamline the performance. ive read about git-annex and also something about git-bigfiles being merged in but i dont know how any of that has progressed, and I am just trying to work out the best way to handle this large site. Happy Cake Oven --> -[__]- -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina wrote: > What I'm looking for is to upload/create the remote branch in github > from inside my local branch, without having to checkout master in > order to do so. In that case, do exactly what you did, except don't checkout master. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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
Re: [PATCH 2/2] git-remote-mediawiki: allow page names with a ':'
On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy wrote: > Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'. > However, it is also possible to call a page Foo:Bar if 'Foo' is not a > namespace. In this case, the actual name of the page is 'Foo:Bar', in the > main namespace. Since we can't tell with only the filename, query the > wiki for a namespace 'Foo' in these cases, but deal with the case where > no such namespace is found. Might not be worth fixing, and it's just a typo in the commit message, but: s/Traditionnally/Traditionally/ ? -- -Dan -- 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
Re: [ANNOUNCE] Sharness - Test library derived from Git
Matthieu Moy writes: > OTOH, having it leave in a subdirectory (e.g. $git/t/Sharness/), and > synchronize with stg like subtree merge would be nice for the user. We > already have something similar for gitk and git-gui, except that the > synchronization is normally one way (subprojects merged into Git, but > merging back changes that were made in git.git in these subprojects is > more painful). Not really. contrib/git-subtree can really help with this. -Dave -- 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
[RFC/PATCH] Only call record_resolve_undo() when coming from add/rm
The REUC extension stores the stage 1/2/3 data of entries which were
marked resolved by the user, to enable 'git checkout -m ' to
restore the conflicted state later.
When a file was deleted on one side of the merge and unmodified on the
other, merge-recursive uses remove_file_from_cache() to remove it from
the result index. This uses remove_index_entry_at(), which calls
record_resolve_undo().
Such REUC entries are in fact even useless: neither 'git checkout -m'
nor 'git update-index --unresolve' can resurrect the file (the former
because there is no corresponding index entry, the latter because the
file is missing one side).
Solve this by taking a more specific approach to record_resolve_undo():
* git-rm and 'git update-index --remove' go through
remove_file_from_cache(), just like merge-recursive. Make them use
a new _extended version that optionally records REUC.
* git-add and 'git update-index conflicted_file' go through the
add_index_entry() call chain. git-apply and git-read-tree use
add_index_entry() too. However, they insert stage-0 entries, which
already means resolving. So even if these cases were not caught
earlier, saving the unresolved state would be correct.
So we can unconditionally record REUC deeper in the call chain.
(git-mv calls remove_index_entry_at() through rename_index_entry_at();
however, it refuses to work on unresolved files. So that's okay too.)
Signed-off-by: Thomas Rast
---
Thomas and me discovered this while hacking on index-v5. It would be
a bit tricky to handle there: the index is structured according to the
directory layout of the files it contains, and the REUC data is the
same as the conflict (stages) data plus a flag bit, for (future)
easier toggling between them. With the behavior before this patch, it
is possible to have directories that do not have any "live" files, yet
contain REUC records. For example, in git.git,
$ git checkout 8e17b34c33^1
$ git merge 8e17b34c33^2
$ g ls-files -s | grep arpa
$ g ls-files --resolve-undo | grep arpa
100644 0d8552a2c6dc3a5fee5360ea2ff468463461e3bf 1
compat/vcbuild/include/arpa/inet.h
100644 0d8552a2c6dc3a5fee5360ea2ff468463461e3bf 3
compat/vcbuild/include/arpa/inet.h
(and several other files in the same commit). So this patch would let
us keep the complexity of that handling down, by not running into such
cases.
builtin/rm.c | 2 +-
builtin/update-index.c | 2 +-
cache.h| 2 ++
read-cache.c | 14 +++---
4 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 90c8a50..145d368 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -226,7 +226,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!quiet)
printf("rm '%s'\n", path);
- if (remove_file_from_cache(path))
+ if (remove_file_from_cache_extended(path, 1))
die(_("git rm: unable to remove %s"), path);
}
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 5f038d6..2e58979 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -196,7 +196,7 @@ static int process_path(const char *path)
* so updating it does not make sense.
* On the other hand, removing it from index should work
*/
- if (allow_remove && remove_file_from_cache(path))
+ if (allow_remove && remove_file_from_cache_extended(path, 1))
return error("%s: cannot remove from the index", path);
return 0;
}
diff --git a/cache.h b/cache.h
index 14d8fd4..616a355 100644
--- a/cache.h
+++ b/cache.h
@@ -378,6 +378,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define rename_cache_entry_at(pos, new_name) rename_index_entry_at(&the_index,
(pos), (new_name))
#define remove_cache_entry_at(pos) remove_index_entry_at(&the_index, (pos))
#define remove_file_from_cache(path) remove_file_from_index(&the_index, (path))
+#define remove_file_from_cache_extended(path, flags)
remove_file_from_index_extended(&the_index, (path), (flags))
#define add_to_cache(path, st, flags) add_to_index(&the_index, (path), (st),
(flags))
#define add_file_to_cache(path, flags) add_file_to_index(&the_index, (path),
(flags))
#define refresh_cache(flags) refresh_index(&the_index, (flags), NULL, NULL,
NULL)
@@ -522,6 +523,7 @@ static inline enum object_type object_type(unsigned int
mode)
extern int remove_index_entry_at(struct index_state *, int pos);
extern void remove_marked_cache_entries(struct index_state *istate);
extern int remove_file_from_index(struct index_state *, const char *path);
+extern int remove_file_from_index_extended(struct index_state *, const char
*path, int save_reuc);
#define ADD_CACHE_VERBOSE 1
#define ADD_CACHE_PRETEND 2
#define ADD_CACHE_IGNORE_ERRORS4
diff --git a/read-cache.c b/read-cach
Egit is not included into eclipse bundles
Hi, I have a strong impression that Egit was supposed to be included into the default eclipse distribution starting from Eclipse Helios. May be it was my wild dream that I would like to become true, but I would appreciate any info about why I still can't see it in Juno? Thanks, Eugene -- 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
Re: [RFC/PATCH] Only call record_resolve_undo() when coming from add/rm
Thomas Rast writes:
> Thomas and me discovered this while hacking on index-v5. It would be
> a bit tricky to handle there: the index is structured according to the
> directory layout of the files it contains, and the REUC data is the
> same as the conflict (stages) data plus a flag bit, for (future)
> easier toggling between them. With the behavior before this patch, it
> is possible to have directories that do not have any "live" files, yet
> contain REUC records. For example, in git.git,
>
> $ git checkout 8e17b34c33^1
> $ git merge 8e17b34c33^2
> $ g ls-files -s | grep arpa
> $ g ls-files --resolve-undo | grep arpa
> 100644 0d8552a2c6dc3a5fee5360ea2ff468463461e3bf 1
> compat/vcbuild/include/arpa/inet.h
> 100644 0d8552a2c6dc3a5fee5360ea2ff468463461e3bf 3
> compat/vcbuild/include/arpa/inet.h
We just discovered that this merge is no longer in current git.git. It
went into master as b7f7c079, and the example works with that.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
Re: git with large files...
> "Darek" == Darek Bridges writes: Darek> I use git for many things, but I am trying to work out the Darek> workflow to use git for deployment. Don't. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion -- 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
Re: git with large files...
On Fri, Jul 20, 2012 at 6:54 PM, Randal L. Schwartz wrote: >> "Darek" == Darek Bridges writes: > > Darek> I use git for many things, but I am trying to work out the > Darek> workflow to use git for deployment. > > Don't. Heh. Best to keep in mind that it just doesn't work very well. git-bigfiles, git-annex might help you, but look at the docs and caveats carefully. Perhaps use rsync, unison work better for you. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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
Re: Fix git-svn tests for SVN 1.7.5.
Hi Michael, > > I've fixed the git-svn tests for SVN 1.7 and tested with SVN 1.7.5. > > Thanks. git-svn is not maintained by Junio but by Eric and others on > the list. I'm cc-ing Eric and Ben Walton so they can benefit from > your work. This is fantastic. It's been on my todo list but not a priority for me. I'm glad you've taken the time to scratch this itch though. I'll try to run through this series in the next few days and I can also do some test builds on solaris to see how it plays there. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 4:19 PM, PJ Weisberg wrote: > On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina wrote: > >> What I'm looking for is to upload/create the remote branch in github >> from inside my local branch, without having to checkout master in >> order to do so. > > In that case, do exactly what you did, except don't checkout master. > Why you suggest that? If I demonstrated that origin master or just origin in the current branch doesn't do what I want, i.e, push it to github. -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 6:40 PM, Thiago Farina wrote: > On Fri, Jul 20, 2012 at 4:19 PM, PJ Weisberg > wrote: >> On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina wrote: >> >>> What I'm looking for is to upload/create the remote branch in github >>> from inside my local branch, without having to checkout master in >>> order to do so. >> >> In that case, do exactly what you did, except don't checkout master. >> > Why you suggest that? If I demonstrated that origin master or just > origin in the current branch doesn't do what I want, i.e, push it to > github. In your original email, you had one command that did what you wanted and one that didn't. $ git push origin master $ git push origin feature-work Can you spot the difference between them? Like Konstantin said, you can look into the different options for push.default, but don't expect Git to push one branch when you told it to push another. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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
Re: pushing branches
On Fri, Jul 20, 2012 at 10:58 PM, PJ Weisberg wrote: > In your original email, you had one command that did what you wanted > and one that didn't. > > $ git push origin master > $ git push origin feature-work > > Can you spot the difference between them? > Do'h, now I can see the idiocy that I was doing. If I'm understanding this better, $ git push origin master tells git to push to remote origin, the contents of my master branch. And then, $ git push origin feature-work tells git to push to remote origin to push the contents of feature-work branch. Hence does not make sense to ask git to do "push origin master" while inside feature-work branch. > Like Konstantin said, you can look into the different options for > push.default, but don't expect Git to push one branch when you told it > to push another. > > -PJ > > Gehm's Corollary to Clark's Law: Any technology distinguishable from > magic is insufficiently advanced. -- 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
Re: git with large files...
On Fri, Jul 20, 2012 at 4:28 PM, Martin Langhoff wrote: > On Fri, Jul 20, 2012 at 6:54 PM, Randal L. Schwartz > wrote: >>> "Darek" == Darek Bridges writes: >> >> Darek> I use git for many things, but I am trying to work out the >> Darek> workflow to use git for deployment. >> >> Don't. > > Heh. Best to keep in mind that it just doesn't work very well. > git-bigfiles, git-annex might help you, but look at the docs and > caveats carefully. > > Perhaps use rsync, unison work better for you. I'm not sure if it was the "big files" part that Randal was responding to. IIUC it was the "using git for deployment" part. Packaging tools (Makefiles, .rpm, .deb, etc) are a better suited for deploying software. -- David -- 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
Re: [PATCH v2] difftool: only copy back files modified during directory diff
On Thu, Jul 19, 2012 at 10:34 AM, Junio C Hamano wrote: > David Aguilar writes: > >> Perhaps something like this... > > Yeah, like that ;-). Hmm.. this one was potentially data-losing. Sorry for not catching that in 7e0abcec103b3649943b236881cf88e8fd6cf3a4. $ git tag --contains 7e0abcec103b3649943b236881cf88e8fd6cf3a4 v1.7.11 v1.7.11.1 v1.7.11.2 maint, please? I don't like complexity either, but adding a --symlinks option (and making it the default) to create symlinks instead of copies really does seem like the way to go long-term. Then we can avoid the whole copy-back business when in this mode. I'll start exploring this unless you beat me to it, Tim ;-) -- David -- 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
